[05:18:25] *** peda has joined #JNode.org
[05:51:09] *** tgiphil has joined #JNode.org
[05:52:06] *** [1]tgiphil has joined #JNode.org
[05:53:31] *** tgiphil has quit IRC
[05:53:31] *** [1]tgiphil is now known as tgiphil
[06:15:34] *** rommanio has joined #JNode.org
[07:18:28] *** loic has joined #JNode.org
[07:55:09] *** rommanio has joined #JNode.org
[08:21:20] <loic> peda: why before a Monitor.NotifyAll() there is a Monitor.enter()?
[08:22:09] <loic> http://gitorious.org/+jnode-new-gc-algo-developers/jnode/new-gc-algorithms/blobs/master/core/src/core/org/jnode/vm/memmgr/def/GCThread.java#line72
[08:59:58] *** rommanio has quit IRC
[09:07:28] *** loic_ has joined #JNode.org
[09:10:34] *** loic has quit IRC
[09:30:14] *** loic_ has quit IRC
[13:24:34] *** ismael has joined #JNode.org
[18:19:32] <peda> loic, that's the normal "semantics" of a Monitor
[18:19:43] <peda> you need to own the lock in order to notify
[18:20:15] <peda> and you also need the lock to call wait() - though wait() will actually automatically release the lock
[18:41:35] *** FabienD has joined #JNode.org
[18:52:36] *** loic has joined #JNode.org
[19:12:20] <FabienD> hi all
[19:14:34] <FabienD> tgiphil: iirc you already came here. right ?
[19:26:10] <tgiphil> yep. last week.
[19:27:28] <tgiphil> wait, that was another site...
[19:27:32] <tgiphil> I'm new here.
[19:29:16] *** ismael has joined #JNode.org
[19:30:36] <ismael> hi
[19:30:41] <ismael> peda: ping?
[19:31:28] <ismael> FabienD: ping?
[19:32:54] *** benoit_ has joined #JNode.org
[19:33:12] <peda> hi ismael
[19:33:18] <ismael> hi
[19:33:21] <peda> hi FabienD, benoit_, tgiphil :)
[19:33:22] <benoit_> hi all
[19:34:10] <ismael> peda: we need to add a flag to objects
[19:34:40] <ismael> peda: to store the number of references for young objects, end their age (in gc generations)
[19:35:09] <peda> ok
[19:35:22] <ismael> i find a class ObjectLayout in org.jnode.wm.classmgr
[19:35:43] <ismael> what modifications are needed to add them?
[19:36:24] <peda> HEADER_SLOTS and a new constant
[19:36:43] <peda> I have to note how JNode expects a pointer
[19:37:09] <peda> if you have a Java reference it is a 32bit pointer which points to the beginning of the data section!
[19:37:18] <ismael> it will be int
[19:37:23] <peda> that's why the header slots have negative index values
[19:37:36] <peda> as the header is "in front" of the pointer location
[19:37:55] <ismael> ok, i saw it
[19:38:36] <ismael> should i modify FLAGS_SLOT too?
[19:38:47] <ismael> i need to store 2 int
[19:39:00] <peda> I wouldn't change it
[19:39:17] <peda> I'm not sure this class is used really anywhere where it is needed
[19:39:32] <ismael> ok
[19:39:37] <peda> so just in case we have some hardcoded values in JNode I would put _your_ 2 int infront of the flags
[19:40:14] <peda> just be sure to make the allocation correct in your implementation so that the header will never reach into other's object data
[19:40:48] <ismael> when you say in front, you mean before?
[19:41:21] <peda> yup :)
[19:41:57] <ismael> the header is before the flags which are before the object data, is it correct?
[19:44:46] <ismael> so to sum up: i modify HEADER_SLOTS (replacing 2 by 4), and i access my 2 int by reading at adress: object adress + FLAGS_SLOT * slot size - HEADER_SLOTS * slot size ?
[19:46:41] <peda> hmm no :)
[19:47:08] <peda> what confused me during my gc studies is, that there are actually 2 pointers to an object
[19:47:31] <peda> one pointer is the one used in the java bytecodes (it directly points to the object's data)
[19:48:10] <peda> and the other pointer is the "raw pointer" pointing to the beginning of the "raw object" (in the view of the allocator)
[19:48:36] <peda> so if you have the java bytecode pointer v: v + TIB_SLOT * slot_size is the pointer to the tib_slot
[19:48:55] <peda> v + YOUR_INT * slot_size is the pointer to your int
[19:49:22] <peda> (and mind, all the _SLOT values are negative, that's what I was arguing with the "2 pointers" above)
[19:50:01] <ismael> so i'll have FIRST_INT = -3; and SECOND_INT = -4
[19:50:08] <peda> yup
[19:50:46] <ismael> thanks a lot
[19:51:00] <peda> no problem :)
[20:01:18] <FabienD> peda: is there a place in the header for the full size (including the header) of the object ?
[20:02:30] <FabienD> I am asking in the case some code compute the size by itself to find bounds of an object in memory (an ignore the fact ismael added some ints in the header)
[20:02:43] <FabienD> *and ignore
[20:03:39] <FabienD> or maybe there is just a constant somewhere for the size of the header ...
[20:04:18] <peda> well, the default heap manager does that
[20:04:30] <peda> but it's just used _in_ the gc
[20:04:47] <peda> hmm.. btw, that's what you should do too ismael
[20:04:59] <ismael> indeed
[20:05:06] <peda> use those two extra slots but don't modify the HEADER_SLOTS
[20:05:14] <ismael> ok
[20:06:20] <peda> but still "honor" these two slots that were allready there.. they're used heavily everywhere for synchronization and for instanceof checks and stuff like that
[20:07:30] <ismael> what is the allocation bitmap used in VmDefaultHeap?
[20:08:05] <peda> for easily knowing if a given pointer points to a valid object
[20:08:27] <peda> (for the conservative mark phase to check a given value if it might be a pointer)
[20:08:37] <ismael> ok
[20:12:04] <tgiphil> what's TIB_SLOT? Thread Information Block ?
[20:13:46] <peda> Type
[20:47:12] <ismael> peda: where the VmMagic class is implemented?
[20:49:58] <peda> ah :) that's a bit tricky :)
[20:50:13] <peda> what are you searching exactly?
[20:50:14] <peda> the asm code?
[20:51:57] <ismael> i'd like to implement methods similar to getObjectColor() for my new slots
[20:52:26] <loic> is there a howto about how to write jnode commands (like cat or something else)
[20:52:48] <ismael> but i can implement it in heap helper like atomicChangeObjectColor
[20:52:48] <loic> i need that to add some gc test utilities
[20:54:00] <peda> ismael: I'd do it like you suggested.. anyway, if you're interessted: org.jnode.vm.x86.compiler.l1a.MagicHelper
[20:54:08] <loic> is it as simple as adding an alias entry in the commands descriptor file?
[20:54:18] <peda> ismael: though you need to be aware of some jit stuff in order to extend it
[20:54:28] <peda> loic: it's mainly as easy
[20:54:39] <ismael> peda: thx i'll have a look
[20:54:41] <peda> loic: though you might have to add your sources to a jar
[20:54:49] <peda> loic: let me search.. we have a howto
[20:55:51] <peda> http://www.jnode.org/node/2546
[20:56:38] <loic> thanks
[20:57:01] <ismael> peda: i will first implement the method as a standard java method to test the gc algorithm, and then if i have time, i'll try to implement it in a bytecode manner in org.jnode.vm.x86.compiler.l1a.MagicHelper
[20:57:49] <peda> ismael: ok, though in this case you wouldn't have a advantage of using the magic way I guess
[20:58:21] <ismael> ok
[21:28:39] <FabienD> I would add : it's even a disadvantage to use the magic if you can do without it. because it's not obvious for a java developer that know nothing about jnode
[21:31:04] <FabienD> good night
[21:31:17] *** FabienD has quit IRC
[22:28:04] <ismael> ++
[22:28:14] *** ismael has quit IRC
[23:25:26] <loic> peda: there's a bug i don't manage to fix
[23:25:28] <loic> http://ups.imagup.com/07/1265110865.png
[23:25:48] <loic> it occurs after the end of GenHeapManager.initialize()
[23:25:55] <loic> but before GenHeapManager.start()
[23:26:38] <loic> it must something that is null, but i have no idea of what is called between initialize and start
[23:47:42] <peda> the callgraph between initialize and start is a bit complicated as there's a huge amount of implicit memory allocation
[23:47:57] <peda> so at a first guess I'd say you have a bug in your allocator code

top