[00:47:01] *** influt has joined #JNode.org
[05:45:52] *** dumaiss has joined #JNode.org
[05:54:02] *** peda_ has joined #JNode.org
[10:17:42] *** FabienD has joined #JNode.org
[14:24:24] *** peda has joined #JNode.org
[14:24:38] <peda> hi FabienD
[16:01:48] <FabienD> hi peda and happy new year !
[16:02:17] <peda> thanks
[16:02:19] <peda> happy new year
[16:02:28] <peda> I read back in the logs
[16:02:33] <peda> about the memmgr
[16:03:05] <peda> did you tell them that we do not have (working) write and/or read barriers?
[16:03:27] <peda> are they aware that conservative copying is quite difficult?
[16:08:11] <FabienD> I told them that for a first attempt (aka their student project), they will just have to move object references between linked lists (actually old and young generation)
[16:08:28] <FabienD> so, it won't imply copying objects for a first time
[16:08:53] <FabienD> read/write barriers (no idea what it is) is related to conservative copying ?
[16:09:05] <peda> yes
[16:09:24] <peda> if they really want to copy they have to:
[16:09:27] <peda> stop the world
[16:09:38] <peda> copy references
[16:09:56] <peda> check the stack and all registers if a value matches the old reference
[16:10:11] <peda> if it matches they can not copy and need to undo it
[16:10:23] <peda> if there's no match they can remove the old rev
[16:10:40] <peda> that's the only possibility I see without barriers and exactness
[16:13:37] <FabienD> I think I understand (a bit) the above strategy
[16:14:35] <FabienD> another strategy (as you told me once) is to imply the compiler in order that it say when it take and release a reference to an object
[16:15:29] <peda> well, not take/realse but allways if you put a value on the stack or pop it from the stack
[16:15:48] <peda> hotspot and jikes are doing that.. they have a so called stack map
[16:16:15] <peda> this is what is called an "exact gc"
[16:16:29] <peda> the gc knows at any time the content of any thread's stack
[16:17:00] <peda> of course that produces much overhead
[16:17:12] <peda> so you additionally introduce gc-safe yieldpoints
[16:17:35] <peda> currently we insert yieldpoints quiet everywhere
[16:17:51] <peda> so, to get exactness there's much to do :)
[16:21:23] <FabienD> so, creating a gc with a young and an old generation without copying object but only their reference is useful for that goal ?
[16:22:29] <peda> I'm not sure I understand the difference bewteen object and reference in that context
[16:22:33] <peda> imho it's the same
[16:23:04] <FabienD> I told the student to not move the objects in memory
[16:24:11] <peda> ah ok, so they keep additional lists/maps that tell about what is young and what is old?
[16:24:22] <FabienD> right
[16:24:26] <peda> ah ok I see
[16:24:28] <peda> cool
[16:24:41] <FabienD> so, it's going in the right direction ?
[16:24:47] <peda> yeah
[16:24:58] <FabienD> good
[16:25:01] <peda> I have no idea if that's going to beat the current gc or whatever
[16:25:11] <peda> but it's a nice direction for another gc
[16:26:10] <FabienD> probably not beat for their first attempt but I saw it might help for the future
[16:26:21] <peda> of course
[16:26:31] <peda> at least experience :)
[16:26:54] <peda> the bad thing is, that fragmentation stays without copying :/
[16:27:18] <FabienD> sure !
[16:27:19] <FabienD> in the hope, they will continue after ;)
[16:27:32] <FabienD> (for a better algo)
[16:27:56] <FabienD> I have not yet looked but there is first commits : http://gitorious.org/+jnode-new-gc-algo-developers/jnode/new-gc-algorithms/commits/master
[16:28:10] <FabienD> (from ismaelm)
[16:28:19] <peda> oh and btw, do you know about the BootableObject interface and did you tell them?
[16:30:50] <FabienD> no
[16:31:37] <peda> I do not understand if fully either
[16:31:50] <peda> but it has todo with bootstrapping jnode
[16:32:09] <peda> for the bootimage (which contains the memmgr) you need a linked binary
[16:32:44] <peda> you do not have the normal dynamic invocation... and to tell the BootImageBuilder something needs to be linked you need BootableObject as marker interface
[16:32:47] <peda> something like that...
[16:33:18] <peda> so if you get strange NPE without stacktrace you mose likely forgot to load a class to the bootimage or you forgot to add BootableObject :)
[16:33:51] <peda> and as I don't fully understand what happens there I would suggest to the students to copy the VmDefaultHeap
[16:33:57] <peda> and modify it as they need it
[16:34:09] <peda> and not change the accessibility
[16:34:24] <peda> as this might produce strange link problems
[16:34:57] <FabienD> I don't see how changing visibility might produce problems
[16:35:51] <FabienD> I think they won't share instances of VmDefaultHeap but create their own
[16:36:42] <FabienD> also I have seen that there is BootableHeap and VmDefaultHeap that inherit from AbstractHeap iirc
[16:38:17] <peda> yup
[16:39:29] <peda> but also mind the loadClasses in DEfaultHeapManager
[16:39:42] <peda> if you omit a class you need you get the strange NPEs
[17:57:40] *** peda has quit IRC
[23:48:21] *** FabienD has quit IRC

   January 3, 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 | >