January 27, 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 27, 2010 NOTICE: This channel is no longer actively logged.
[00:08:17] <peda> hmm not 100%[00:08:29] <peda> I think if you added them as compileHighlevel you don't need to[00:08:36] <peda> else you have to add them for sure[00:14:44] <loic_> there is only the package added in the compileHighLevel[00:16:42] <peda> yeah, i.e. all classes in it[00:16:53] <peda> but as I said, I'm not 100% sure this is enough[00:17:31] <peda> to be realy sure just add them to the loader.. the only disadvantage if they're unneeded is a bigger kernel image[00:17:50] *** FabienD has quit IRC[00:18:32] <loic_> peda: ok[00:18:44] <loic_> peda: i've got some compilation problems[00:19:40] <loic_> in my GenHeapManager constructor there is a setWriteBarrier(new GenWriteBarrier(getHelper())); and added loader.loadClass("org.jnode.vm.memmgr.generational.GenWriteBarrier", true);[00:19:48] <loic_> but it doesn't compile[00:20:09] <loic_> without le setWriteBarrier, it compiles well[00:20:17] <loic_> without the*[00:20:32] <peda> do you need the writebarrier for a special reason?[00:20:50] <peda> the writebarriers do not really work[00:21:05] <peda> the code gets called, but triggers a kernel/compiler bug[00:21:15] <peda> I'd just set them to null[00:23:02] <loic_> ismael write its own writebarrier[00:23:14] <loic_> will it work?[00:23:30] <peda> I'm afraid it won't[00:23:35] <loic_> or is the bug on the kernel side[00:23:37] <loic_> :([00:23:38] <peda> there's a bug in the code[00:23:44] <peda> in the compiler actually[00:23:57] <loic_> can it be fix easily?[00:24:09] <peda> I can provide you a fix for it... it will make it work but slow down the code :/[00:25:17] <loic_> i'll take the fix[00:25:23] <peda> :)[00:25:31] <peda> sry about that.. I though Fabien told you[00:25:41] <loic_> and tomorrow , i will ask ismael if he really needs it[00:25:54] <peda> I have to search for it.. but I should have it around somewhere[00:25:54] <loic_> np[00:26:14] <peda> the main problem with our writebarriers is, that we can't turn them on and off[00:26:36] <peda> you you need a "if(gcActive)" in your barrier to speed it up..[00:26:37] <loic_> so they are called to each alloc[00:26:41] <peda> yep[00:26:54] <loic_> ok[00:27:00] <peda> and as it is a method call you _need_ to save all register values before calling the barrier code[00:27:04] <peda> but that's not done[00:27:24] <peda> so you very likely overwrite some register values during your barrier code[00:27:34] <loic_> but this could be done on the kernel side not calling the writebarrier if the gc is active?[00:27:59] <peda> ah, no that works differently:[00:28:30] <peda> the JIT inserts calls to the writebarrier code. For each "put" bytecode but only if there actually _is_ a writebarrier[00:29:08] <peda> so the JIT does something like: WriteBarrier wb = getDefaultHeapManager().getWriteBarrier(); if (wb != null) { /* buggy code */ } ...[00:29:17] <peda> :)[00:29:57] <loic_> ok[00:30:40] <loic_> i'll take the fix and how to save register values[00:30:49] <peda> *searching*[00:34:59] <peda> http://www.won2.de/jnode/memmgr/[00:35:52] <peda> that should make it work.. I tested it a bit and it mainly worked but I can't promise it's bugfree[00:36:16] <peda> and remember: if enabled the writebarrier code gets called from very early on![00:36:29] <peda> even before the memmgr gets setup![00:37:05] <peda> so be really carefull with what you do _in_ the writebarrier methods.. and try to protect everything with a "if (gcActive)"[00:37:36] <peda> if you do anything wrong here you'll get really strange behaviour with very early kernel crashes.. ;)[00:43:06] <loic_> peda: is there any tools to apply the patch?[00:45:24] <peda> patch?[00:45:42] <peda> I'm used to commandline, there it's patch -p1 < foo.patch[00:46:17] <peda> there should be something similar in eclipse's team (svn) utils[00:49:08] <loic_> command line is ok for me :)[00:50:54] <loic_> i will discuss with ismael tomorrow and if we really need writebarrier[00:51:16] <loic_> i will apply the patch[00:51:45] <loic_> see you[00:51:45] <loic_> bye[00:52:02] *** loic_ has quit IRC[05:24:17] *** peda_ has joined #JNode.org[08:48:04] *** loic has joined #JNode.org[09:52:15] *** Xianwen has quit IRC[09:52:33] *** Xianwen has joined #JNode.org[14:39:50] *** peda_uni has joined #JNode.org[14:44:14] <loic> peda_uni: hi[14:45:12] <peda_uni> hi loic[14:46:47] <loic> peda_uni: I'm having some trouble with the jnode boot with our new gc[14:47:11] <loic> i'm just trying to see how the gc behave during the boot sequence[14:47:19] <loic> and i'm having this : http://www.phpboost.com/upload/jnode_panic.png[14:47:45] <peda_uni> ok.. the funny ones.. :)[14:48:31] <peda_uni> hmm[14:48:31] <loic> it's obvious that it comes from something wrong in our gc implementation[14:48:42] <peda_uni> that's a difficult one[14:49:05] <peda_uni> give me a bit.. :)[14:49:10] <loic> but i'm trying to put traces to understand the boot sequence and try to see from where it could come but i didn't manage[14:49:42] <peda_uni> ok[14:49:44] <loic> <peda_uni> "give me a bit.. :)" : 1[14:49:47] <loic> :D[14:49:48] <peda_uni> but be carefull:[14:50:00] <peda_uni> "foo" + a + "bar" <-- stuff like that[14:50:07] <peda_uni> all the implicit "new"s .. ;)[14:50:13] <loic> ok[14:50:23] <loic> that's my debug statements that causes the panic[14:50:49] <peda_uni> ah? so you know the problem?![14:51:27] <loic> no, but i just realize of these new during the string concatenation[14:51:45] <loic> but i though "a" + "b" was resolved at compilation time[14:52:14] <loic> i just say something wrong[14:52:29] <loic> i use parameters in my debug calls so it couldn't be resolved at compilation[14:52:33] <loic> thanks[14:52:38] <peda_uni> good :)[14:56:29] <loic> it VxWorks better now :)[14:58:05] <peda_uni> cool :)[15:24:28] *** loic has quit IRC[16:15:07] *** Xianwen has quit IRC[18:27:50] *** loic has joined #JNode.org[19:08:16] <loic> peda: the start method of the DefaultHeapManager is called at compilation time or at runtime?[19:12:43] <loic> peda_uni: that's just in order to know where i can put my "new" (except in the constructor) in my GenHeapManager[20:07:01] <peda_> hmm I have to look, one sec[20:09:21] <peda_> initialize is the first one that gets called (mostly the first thing in the boot process at all)[20:09:33] <peda_> if that method was called, memory allocation _has_ to work[20:09:59] <peda_> start() gets called during bootup but at a much later time (at this point everything should work)[20:10:09] <peda_> and the system expects that the GC will work after start() got called[20:10:43] <peda_> so initialize() -> no "new"s! Constructor and start() -> may use "new"[20:17:51] <loic> peda_uni: ok, but what about the DefaultHeapManager[20:18:17] <loic> http://gitorious.org/+jnode-new-gc-algo-developers/jnode/new-gc-algorithms/blobs/master/core/src/core/org/jnode/vm/memmgr/def/DefaultHeapManager.java#line253[20:18:59] <loic> there is several "new" in it[20:21:29] <peda_> yes, in start() and in the Constructor[20:21:39] <peda_> but there are no "new"s in initialize()[20:27:00] *** FabienD has joined #JNode.org[20:30:43] <peda_> hi Fabien[20:31:35] <loic> hi[21:39:12] <loic> peda_uni: I'm having some debug trouble[21:39:15] <loic> http://rifers.org/paste/show/384[21:39:26] <loic> that's my debug code[21:40:50] <loic> here is what i have on boot : http://www.phpboost.com/upload/jnode_panic_8941b.png[21:41:37] <loic> the fisrt Unsafe.debug statement is executed, but not the (1.5) or the (2)[21:41:46] <loic> I don't understand why[21:42:17] <loic> is the Unsafe.debug () method synchronous?[21:43:24] <loic> by that i mean does it wait for the text to be printed on screen or is the text message putted in a message queue that will be displayed.[21:44:22] <loic> In the second case, it may explain my issue with my debug messages but not with the real panic one.[21:45:01] <loic> So my second question is : Are notify() and wait() methods from object allowed in the GC?[22:01:56] <loic> peda_uni: i ran some other tests and it appears that the "real panic" is raised when accessing isRunning which is a member of the class and is initialize with "false"[22:02:44] <loic> this class is instanciated in the GenGCHeapManager.start() method with a "new"[22:03:50] <loic> http://gitorious.org/+jnode-new-gc-algo-developers/jnode/new-gc-algorithms/blobs/master/core/src/core/org/jnode/vm/memmgr/generational/GenGCSweepThread.java[22:04:02] <loic> and http://gitorious.org/+jnode-new-gc-algo-developers/jnode/new-gc-algorithms/blobs/master/core/src/core/org/jnode/vm/memmgr/generational/GenHeapManager.java[22:04:35] <loic> FabienD: any ideas?[22:14:35] <FabienD> hi all[22:16:24] <loic> FabienD: hi[22:18:00] <FabienD> loic: it's unbuffered and so write synchronously to serial line[22:18:48] <FabienD> and Unsafe.debug is not thread safe -> it might eventually cause issues[22:21:08] <loic> FabienD: ok[22:21:39] <loic> but any ideas about the problem accessing classes members?[22:27:58] <peda_> oh sry, I missed that.. *reading*[22:28:28] <FabienD> for such case, I suggest a catch(Throwable) and display (unsafe.debug) of the member variable[22:29:20] <FabienD> loic: that code is run by the gc thread, right ?[22:31:09] <peda_> loic: the out-of-order debug statements might be cause by "illegal" access[22:31:53] <peda_> loic: this is something I'm not sure about.. but perhaps "this" is not present in that early startup code[22:32:38] <peda_> "this" usually is kept on the stack, but we have a "root bootup stack" perhaps some problems with that..[22:33:05] <loic> peda_:i don't think so[22:33:19] <loic> because i found this in the current implementation[22:33:21] <loic> http://gitorious.org/+jnode-new-gc-algo-developers/jnode/new-gc-algorithms/blobs/master/core/src/core/org/jnode/vm/memmgr/def/DefaultHeapManager.java#line257[22:33:48] <peda_> right[22:34:18] <loic> I try to put all in the GenHeapManager constructor[22:34:35] <loic> but in this case, "this" is not defined and i got a compilation error[22:34:55] <peda_> no you're right.. what I said does not make sense[22:35:15] <peda_> btw about notify and wait[22:35:27] <loic> i'm now trying to do the new in the constructor and setting the "this" reference by an additional method call on these objects in the GenHeapManager.start()[22:35:34] <peda_> you may use them.. but it will trigger an allocation![22:37:14] <loic> what synchronized mecanism could i use?[22:37:42] <loic> i mean, what can i use that won't trigger any allocation[22:43:08] <peda_> there are two possibilities and it depends if you want to have it smp safe or not[22:43:16] <peda_> one is scheduler/Spinlock[22:43:31] <peda_> the other one is to directly work on a Monitor object[22:44:00] <peda_> if you use that, wait and notify are ok.. but if you do it on a normal Object internally a Monitor Object will be created[22:45:24] <peda_> oh[22:45:32] <peda_> I just saw a possible bug in your code:[22:46:47] <peda_> MemoryBlockManager has a "bug": if you call getFreeMemory() without ever having allocated anything from MemoryBlockManager it will crash[22:47:21] <peda_> so either fix that in MemoryBlockManager or allocate one block before calling getFreeMemory() ... otherwise you'll get strange behaviour ;)[22:47:58] <loic> lol ok for the getFreeMemory() bug[22:48:06] <peda_> :)[22:48:09] <loic> i'll take a monitor for the lock[22:48:35] <loic> just a question about the monitor[22:48:57] <loic> i will just have to use monitor.Wait() and monitor.Notify()[22:50:52] <peda_> yes[22:51:39] <peda_> if you have a "synchronized(this) { this.wait() ]}" or something like that it kind of translates to "new Monitor().wait()"[22:52:05] <peda_> though the Monitor object is singleton for "this" .. but anyway, that's why you'll get a "new" once[22:57:53] <loic> i've got some issue with my monitor[22:58:02] <loic> i'd like to have a mutex instead[22:58:50] <loic> because in to order to wait for the thread ends, i use monitor.Wait(0L); and at the end of my thread a monitor.NotifyAll()[22:59:17] <loic> peda_: but what if the NotifyAll() is reached before the Wait()[22:59:57] <peda_> then you have a deadlock :)[23:00:05] <loic> it will simply ends the thread running and when the thread that was waiting for cpu will take cpu, it will wait forever[23:00:53] <loic> i don't know mutex implementation pattern with the synchronised api[23:01:19] <peda_> what about the SpinLock?[23:01:41] <loic> a solution that comes to mind is to use Wait(some value) in a while and check the thread state[23:01:54] <loic> i don't understand the spinlock goal[23:02:18] <peda_> hmm can you explain me your problem?[23:02:31] <peda_> i.e. where do you want to use the mutex[23:03:04] <peda_> and what do you expect todo.. perhaps that will help me find a solution as I am currently not sure what you need[23:03:27] <loic> in this method i trigger the thread start[23:03:31] <loic> no problem for that[23:03:42] <loic> but i have sometime to wait for the thread ends[23:04:17] <loic> and in this case there is a problem with the wait() notify() api in case the notify came before the wait()[23:06:47] <peda_> ah[23:06:50] <peda_> ok[23:07:20] <peda_> I think I understand now.. what I said above is not complete: The semantics of synchronized also uses enter()[23:08:13] <peda_> give me a bit :)[23:11:07] <peda_> so..[23:11:24] <peda_> you should not use wait() notify() but enter/exit[23:11:30] <loic> ok[23:11:33] <peda_> I think that solves your problem, isn't it?[23:11:42] <loic> i take a look[23:12:00] <peda_> only _one_ thread may have the lock. In order to acquire the lock you have to call enter()[23:12:17] <peda_> if it works, you're the owner.. if it does not work, you get into the wait-queue[23:12:50] <peda_> if you call exit() you release the lock. But if there is a waiting thread, it gets notified[23:13:05] <peda_> and you can be sure there are no sync problems[23:14:26] <loic> that was exactly what i wanted, thanks[23:42:29] <loic> peda_: with monitors, only the owner thread could use the enter method?[23:47:47] <loic> peda_: it means that monitors could not be instanciate statically (i mean at compilation)[23:54:11] <peda_> I do not see how one relates to the other[23:54:27] <peda_> one fact indeed is, that you need to allocate it during runtime[23:54:36] <peda_> (i.e. the "new Monitor()" statement)[23:54:50] <peda_> the enter method may of course be used by any thread[23:55:01] <loic> ok[23:55:13] <loic> i will work on it tomorrow[23:55:16] <peda_> though just _one_ thread can own the lock[23:55:28] <peda_> all others will wait until they own the lock[23:55:32] <peda_> ok[23:55:38] <loic> now, time to sleep for me[23:55:42] <peda_> :)[23:55:43] <loic> thanks for all[23:55:44] <peda_> me too[23:55:47] <peda_> no problem[23:55:48] <peda_> cu[23:55:49] <loic> see you tomorrow[23:55:49] <peda_> gn8