On 11/1/06, Robin Garner <[EMAIL PROTECTED]> wrote:
> Interesting idea! It seems the real issue is "marking and sweeping" the > vtables. A stab at categorizing the approaches: > > a) > Force vtables to be as similar to ordinary java objects as possible. The > upside: existing GC algorithms will work unaltered. The downside is > vtables > of vtables of vtables... This has already been discussed at length. > > b) > Force vtables to live and die in a unique "vtable space". The big > challenge seems to be building a custom GC algorithm that is simpler and > less invasive than doing a) above. Most likely the performance of the > custom GC algorithm will never be an issue. Vtables have some very > interesting properties that may make this doable. The 4 (or 8) bytes at > offset "K" always point to a class structure which, in turn, always has a > pointer at offset "Z" back to the vtable. There are way fewer vtables > than > objects. For practical reasons, it can be assumed that vtables will > always > be pinned. The number of class structs/objects is no greater than the > number of vtables. I guess ... the issue of where vtables and other classloader related structures lives seems to me to be simple engineering. Whether they are malloced in the C heap or 'new'ed in an immovable Java heap makes little difference. After all they are very very small compared to the rest of the heap. > A half-baked scheme that might be good enough: Partition off 50 megabytes > as a hard, fixed vtables space. Then do a word-by-word scan to pick up > candidate pointers class structs. Then filter the candidate class struct > pointers by verifying the back pointers. Occasionally there might be > "floating garbage" with this approach but a valid, live vtable should > never > be accidentally freed. The filtered set are the "live" vtables. Next > scan > the live vtables looking for members that were never marked by the regular > GC as mentioned below. When found, zero the vtable, link-list on a free > vtable space list, mark the class struct as "vtable-less". Process the > "vtable-less" class struct, etc... This sounds a bit complicated - i'm sure it could be done by maintaining linked lists of all the classes loaded by each classloader (pointing to vtables from there) and traversing it. Traverse this once, propagating the mark bits upwards and you are done.
You are right. Your approach is way simpler. It makes a lot of sense. I was too sleepy to think through this clearly.
