January 26, 2010 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
January 26, 2010 NOTICE: This channel is no longer actively logged.
[01:17:10] *** echelog-1 has joined #JNode.org[10:11:51] *** peda_uni has quit IRC[10:12:11] *** peda_uni has joined #JNode.org[10:47:30] *** peda_uni has quit IRC[11:01:53] *** loic has joined #JNode.org[11:28:21] *** benoit has joined #JNode.org[14:06:06] *** Xianwen has joined #JNode.org[14:06:43] <Xianwen> Hey! Has anyone tried to boot Jnode from a usb pen drive?[16:29:23] *** Xianwen has quit IRC[16:29:23] *** Mazon has quit IRC[16:29:43] *** Mazon has joined #JNode.org[16:29:43] *** Xianwen has joined #JNode.org[16:48:54] *** Xianwen2 has joined #JNode.org[16:49:34] <Xianwen2> Hey! Has anyone tried to boot Jnode from a usb pen drive?[17:05:41] *** Xianwen2 has quit IRC[18:24:34] *** loic has joined #JNode.org[18:32:00] *** FabienD has joined #JNode.org[18:45:30] <FabienD> hi all[18:45:39] <FabienD> Xianwen: welcome to jnode ![18:54:05] <loic> hi[18:54:27] <loic> Just a question about the existing garbage collector[18:54:58] <loic> is there a service that could give the heap in which an object is?[18:57:03] <loic> for example something that looks like "VmDefaultHeap myObjectHeap = Vm???.getObjectHeap(myObject);" and then "myObjectHeap.free(myObject);"[19:02:42] <peda> no :/[19:02:49] <peda> you have to travel the heap list[19:03:09] <peda> and hi Xianwen[19:03:22] <peda> Xianwen: I'm not aware of anyone trying to boot from a usb pen[19:03:44] <peda> Xianwen: but it should be fairly easy. JNode has two files: kernel and an "initrd"[19:04:12] <peda> Xianwen: so if you have a bootloader for usb you can simply configure it to use the JNode kernel and initrd and it *should* work ;)[19:04:26] <loic> thanks[19:05:51] <peda> loic: how is it going with the GC?[19:06:54] <loic> we've got some little problems (like the one above), but nothing more serious[19:07:07] <peda> ok cool[19:07:24] <loic> peda: I hope we will have a first version by the end of the week[19:07:39] <loic> peda: if not it will be for next week :)[19:07:42] <peda> wow cool[19:07:43] <peda> :)[19:08:13] <peda> btw, have you solved the "benchmarking" problem? i.e. did you find anything usefull for actual performance tests?[19:08:33] <peda> I found my self that this is quite a problem because the "big ones" don't work in JNode :/[19:08:40] <loic> peda: not yet[19:09:20] <loic> ped:a: our first test will be launching jnode and trying to see if memory is garbaged[19:09:39] <loic> peda: after that we will try stress tests :D[19:10:31] <loic> I'm currently trying to build jnode with our new gc instead of the existing one[19:11:01] <loic> but i have a error /jnode/all/build-x86.xml:193: java.lang.RuntimeException: Cannot find a method[19:11:15] <loic> at org.jnode.vm.compiler.EntryPoints.testMethod(EntryPoints.java:287)[19:11:38] <loic> unit tests are needed in order to make the build work?[19:13:25] <peda> no[19:13:27] <peda> hmm[19:13:43] <peda> how did you try to build?[19:13:49] <peda> cd-x86-lite?[19:13:57] <loic> cd-x86[19:14:20] <peda> hmm[19:14:20] <loic> I replace this <property name="jnode.memmgr.plugin.id" value="org.jnode.vm.memmgr.def"/> by this <property name="jnode.memmgr.plugin.id" value="org.jnode.vm.memmgr.generational"/>[19:14:47] <loic> and i have added descriptors for generational and set it as default in properties file[19:15:22] <peda> ok and what about the compiler?[19:15:29] <peda> did you add it there too?[19:16:43] <loic> i have added this addCompileHighOptLevel("org.jnode.vm.memmgr.generational"); in AbstractBootImage if it's what you wanted to know[19:16:53] <peda> yep[19:16:55] <loic> AbstractBootImageBuilder*[19:17:04] <peda> hmm[19:17:11] <loic> and also addCompileHighOptLevel("org.jnode.vm.memmgr.generational.trigger");[19:17:33] <peda> can you try cd-x86-lite?[19:17:54] <loic> ok[19:17:57] <peda> I'm not 100% about cd-x86, I think it builds 32bit and 64bit CD images, but it might do a bit more[19:18:03] <peda> cd-x86-lite just builds the 32bit CD[19:18:50] <loic> in our implementation, we use Queue and ConcurrentLinkedQueue[19:19:18] <loic> they are not loaded with addCompileHighOptLevel in AbstractBootImageBuilder[19:19:18] <peda> this is the lock-free implementation in concurrent?[19:19:45] <loic> whet do you mean by lock free?[19:19:53] <loic> what*[19:20:08] <loic> with no lock?[19:20:10] <peda> yes[19:20:22] <peda> the ones in the concurrent package of java, right?[19:20:29] <loic> same error with cd-x86-lite[19:20:34] <loic> yes[19:20:49] <peda> ok, that might trigger a problem[19:20:54] <loic> java.util.concurrent.ConcurrentLinkedQueue[19:21:05] <peda> yep, these are lockfree implementations[19:21:27] <peda> they are nice, but they might lead us to two problems:[19:22:02] <loic> performances and dead locks?[19:22:09] <peda> 1. I'm not sure the concurrent package works in JNode. We have support for CAS(2) but I'm not sure if someone made it work in concurrent package[19:23:01] <peda> 2. I'm not sure if it's possible to "link" these classes into the bootimage of JNode, but you will need that. That happens as the ConcurrentLinkedQueue code is in the java packages and so it is in the initrd[19:23:30] <peda> but the GC is in the kernel, which runs and initialises the GC _before_ the initrd gets loaded[19:23:52] <loic> the concurrent is not needed anymore[19:24:05] <loic> i change it to LinkedList[19:24:16] <peda> no, wait[19:24:23] <peda> I think you didn't get the point[19:24:28] <peda> LinkedList has the same problem[19:24:30] <peda> :*)[19:24:48] <peda> but anyway. This should give a runtime error, not a compile time error[19:25:08] <peda> FabienD: do you have an idea regarding the build problem above?[19:27:24] <FabienD> Xianwen: in the past, I were able to boot jnode on memory stick. it should be the same for an usb drive (maybe I tried once but I am not sure)[19:27:29] <loic> is it possible to use a list or a queue implementation that won't cause this problem?[19:28:12] <peda> give me a second..[19:28:17] <loic> ok[19:30:51] <loic> i have to go.[19:30:55] <peda> ok, it should be like that:[19:30:57] <peda> ok[19:30:58] <peda> :)[19:30:58] <loic> I'll be back in 30 minutes[19:31:10] <peda> k, I'll be here[19:32:55] <loic> if you want, you can put the explainations here, and i will read those in a few moments[19:35:40] <FabienD> peda: I have no precise idea about that but it remind me that once I got problem while working with concurrent api in jnode[19:36:26] <FabienD> iirc there was something called "park" (for a thread or lock, I don't remember) in the lower levels of the openjdk[19:37:02] <FabienD> and some things were not implemented or needed a fix[19:37:25] <FabienD> I can't say more since it was maybe one year ago or so[19:37:51] <FabienD> ... maybe not related to loic's problem ...[19:38:32] <FabienD> what's sure is that not everything is binded between openjdk and jnode ;)[19:40:19] <peda> yup :)[19:40:31] <peda> but I know that we have CAS support in JNode[19:40:53] <peda> so in theory it should not be a problem to make concurrent work[19:41:19] <peda> anyway, I'm still not sure _where_ loic needs it. If it is in the early bootup code it should not work[19:41:31] <peda> do you think so too?[19:41:53] <peda> the classes are in the initrd but the GC runs before initrd is loaded and initialized[19:51:57] <FabienD> CAS stands for Clear And Set (atomically), right ?[19:52:45] <peda> Compare.. yes[19:53:15] <peda> actually Compare and Swap, but atomic yes[19:57:01] <FabienD> but what do you mean exactly by CAS ? we have a jnode specific api for doing that ?[19:57:02] <FabienD> *by CAS support[19:57:23] <peda> yes[20:01:42] <FabienD> it might be useful for the Atomic* classes but I never looked at their implementation[20:03:39] <FabienD> aha ![20:04:02] <FabienD> AtomicInteger.compareAndSet is calling unsafe.compareAndSwapInt[20:04:25] <FabienD> and that's a native method[20:04:25] <peda> but Unsafe from Sun right?[20:04:30] <peda> not our unsafe[20:04:49] <peda> and it's not implemented I guess? :)[20:04:49] <FabienD> yeah, sun.misc.Unsafe[20:05:38] <FabienD> it looks implemented but there is that comment : //todo make sure it's atomic[20:05:54] <peda> hmm :)[20:05:56] <FabienD> so it might be broken or not[20:07:22] <FabienD> I think it's just not atomic at all[20:07:30] <peda> heh[20:07:32] <peda> where is it?[20:08:10] <FabienD> look : http://rifers.org/paste/show/383[20:08:41] <peda> heh[20:08:43] <peda> yeah[20:08:45] <peda> :D[20:08:45] <FabienD> it's in here : /core/src/openjdk/vm/sun/misc/NativeUnsafe.java[20:09:09] <peda> and it would be so easy.. as address has a compareAndSwap method in it :)[20:09:52] <FabienD> really ?[20:10:51] <peda> yup[20:11:11] <FabienD> I see only atomicAdd, atomicAnd ...[20:11:23] <FabienD> but no compare* method[20:11:32] <loic> i'm here[20:12:41] <peda> FabienD: sry, it's called "attempt"[20:12:43] <peda> ;)[20:13:01] <FabienD> peda: there is some attempt* methods that might or might not do what you said but the javadoc is not clear to me[20:13:07] <FabienD> peda: ok :)[20:13:19] <loic> We don't need in our gc implementation concurrent list, just list implementations like LinkedList[20:13:25] <FabienD> peda: the javadoc should be made clearer[20:13:41] <peda> loic: Ok, but let me try to explain the problem with that[20:14:07] <loic> peda: ok[20:14:08] <FabienD> peda: it's part of jikes, so I wonder if I can change the javadoc ...[20:14:10] <peda> when JNode boots up one of the first things it does is to initialize the GC[20:14:44] <peda> or let's say the Memory manager[20:15:08] <peda> if you do a "new" before the Memory Manager is working you get unspecified behaviour[20:15:54] <peda> I'm now not sure how you want to use the List and all that. But you have to be aware of several "side effects"[20:16:53] <peda> if you use a LinkedList you have several implicit "new"s (i.e. object allocations): If you declare the List, the .class Object gets loaded (->new), the list itself gets created (->new), all the nodes (->new)[20:17:22] <peda> if you make use of the "synchronized" statement in your Java code this might trigger a new[20:17:25] <peda> and so on[20:17:42] <peda> the .class file is in the initrd file[20:17:50] <peda> the GC and Memorymanager is in the kernel file[20:18:34] <peda> now if you boot up, the kernel gets started, tries to initialize the Memory manager, tries to init other hardware stuff (allready heavily using "new")[20:18:46] <loic> peda: i understand that but there are "new" in the current implementation http://tinyurl.com/ybxf2u6[20:18:49] <peda> then it tries to load the initrd, unpack it,... (dozens of "new"s)[20:19:10] <loic> by there are "new", i mean explicit "new"[20:19:32] <peda> yes! but that depends on the order of operation[20:19:52] <peda> the Constructor of HeapManager gets called during Building JNode ;)[20:20:09] <peda> so every "new" in there gets included in the kernel boot image[20:20:18] <peda> though there's yet another exception to that:[20:20:28] <loic> i see the point[20:20:43] <peda> you _need_ to include the class file information into the kernel boot image as well if you want it to work[20:21:18] <peda> and to include every information that is needed all classes _have_to_ implement BootableObject[20:21:20] <loic> so we could use "new" in methods called at the compilation time[20:21:37] <peda> yes, but only on Objects that implement BootableObject[20:21:51] <peda> if they do not, the linking goes wrong and you get a kernel crash[20:22:24] <loic> ok, so we have to implements our own linkedlist implementing BootableObject[20:22:37] <FabienD> is there a way to prevent that at build time (like a build failure) ?[20:24:08] <FabienD> it would be useful but I wonder how to do and even if it's possible to detect that at build time ...[20:24:41] <peda> FabienD: Actually I suspected it to fail.. but for me it once didn't.. so not sure what happens[20:25:09] <peda> FabienD: but the problem is, that the bytecode does not tell you the runtime type of an object.. so perhaps you can never be sure during buildtime[20:25:12] <peda> not sure[20:25:24] <peda> loic: yes, that's the only possibility I see right now[20:25:48] <peda> loic: there might be other ways.. but to avoid anoying debuging sessions I'd implement my own list[20:26:18] <peda> loic: Btw, I think we have some lowlevel collection classes that implement BootableObject.. perhaps it contains a list[20:26:21] <peda> let me search...[20:26:57] <FabienD> I found BootableArrayList[20:26:59] <peda> loic: indeed we have[20:26:59] <peda> yep[20:27:03] <loic> peda: :)[20:27:08] <loic> thanks[20:27:24] <peda> it extends VmSystemObject which should be a BootableObject[20:28:03] <loic> just a question[20:28:34] <loic> we want to use a list for storing objects to delete[20:29:02] <loic> so when we will do the collection in our gc thread[20:29:14] <loic> we will add the object to the list[20:29:32] <loic> this will be at run time[20:29:42] <peda> yes[20:29:47] <loic> and may cause a new[20:29:51] <peda> yes[20:30:01] <loic> so there should be the same problem[20:30:03] <peda> actually I'd say it will cause a new :)[20:30:06] <peda> yes[20:30:22] <peda> but you can and should avoid that by a similar trick as in the current gc:[20:30:38] <loic> you mean marking objects?[20:30:58] <peda> in the current GC if the GC runs all threads are stopped anyway[20:31:35] <peda> and if the GC itself triggers a "new" the allocObject-implementation has an extra check "if (isGCactive) {...}"[20:31:58] <peda> and the memmgr keeps an extra 16MB heap object for allocations during a GC run made by the GC[20:32:25] <peda> you have to be aware that your list itself will be garbage.. so this might help you with that at the same time:[20:32:55] <peda> at the end of _your_ gc run, if you deleted the objects stored in the list you simply delete the complete "gc heap" at once[20:33:13] <peda> as you can be sure only the GC could reach any object within it[20:33:24] <peda> in case that makes any sense for you :)[20:33:56] <loic> i see[20:34:58] <peda> actually that's just an idea... the main point is, that you have to be carefull to not produce more new garbage objects than you collect :)[20:34:59] <loic> could i have the list of the methods of the current GC that are called at compilation time[20:35:14] <peda> one sec[20:36:15] <peda> core/src/core/org/jnode/vm/memmgr/def/DefaultHeapManager.java#allocObject(VmClassType<?> vmClass, int size)[20:36:47] <peda> there is a "if (gcActive) {" in it[20:37:02] <FabienD> peda: interesting that private heap for the GC. it's an idea and not something we have atm ?[20:37:08] <loic> if have already found it[20:37:43] <peda> FabienD: well we have it, but for debug purpose: if the GC allocs, we write a debug message to kdb stating it's a "bug" ;)[20:37:53] <peda> FabienD: our current rule was: GC may not alloc[20:39:01] <FabienD> yeah, it's the ideal situation and it could be reach if you allocate enough memory statically (outside of a gc run)[22:01:48] *** galatnm has joined #JNode.org[22:57:47] *** loic has joined #JNode.org[23:04:13] *** loic_ has joined #JNode.org[23:47:41] <loic_> peda: when i'm using my own classes in the GC, do i need to load them manually in my own HeapManager method loadClasses(VmClassLoader loader) with a loader.loadClass("org.jnode.vm.memmgr.generational.MyClass", true); ?