harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Class unloading support - tested one approach
Date Wed, 01 Nov 2006 19:22:23 GMT
On 11/1/06, Robin Garner <robin.garner@anu.edu.au> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message