Ivan Volosyuk wrote:
Robin, thank you for this information. I want to ask a few questions
to check that I understand you correctly.
On 10/31/06, Robin Garner <[EMAIL PROTECTED]> wrote:
MMTk implements several algorithms for retaining the reachable objects
in a graph and recycling space used by unreachable ones. It relies on
the host VM to provide a set of roots. It supports several different
semantics of 'weak' references, including but not confined to those
required by Java.
If you can implement class unloading using those (which the current
proposal does), then MMTk can help.
If you want to put a pointer to the j.l.Class in the object header, MMTk
will not care, as it has no way of knowing. If you put an additional
pointer into the body of every object, then MMTk will see it as just
another object to scan.
Does this mean that MMTk will not work with VM in which VTable pointer
(a pointer in object header) points to other heap object?
If the GC map for the object includes this pointer, MMTk will trace it,
otherwise not. MMTk's view of an object is abstracted through the
implementation-specific ObjectModel interface, which provides isolation
from the implementation details. When I talk about 'object header',
more precisely I'm talking about the fields that MMTk doesn't see, since
MMTk has no real concept of an object header.
In JikesRVM, the TIB is actually an Object[] that lives in the heap - we
don't trace TIBs from objects, but (AFAIR) via roots from the VM. If
you want to trace them during GC, just give MMTk GC maps that include
them, and it will. The invariant is simply that the ObjectModel must be
able to understand the vtables.
Remember MMTk is a memory manager, not a Java VM!
Conversely, supporting some exotic class unloading mechanism in MMTk
shouldn't be hard and wouldn't deter me from trying it out. If (as a
wild idea) you wanted to periodically scan the heap, and count all
references to each classloader, you could implement this with very
little work as a TraceLocal object, and then extend the GC plan you
wanted with an additional GC phase that would periodically do one of
these scans after a major GC (for example).
This looks similar to approach #2 discussed here, agree?
If what you mean is Aleksey's 'Mark and scan' proposal, yes, that sounds
right. I'm not advocating it as 'the solution' because I don't know
what's best here, just saying that implementing it in MMTk wouldn't
necessarily be hard.
cheers
