Re: [drlvm] Class unloading support

[Robin Garner <ro...@anu.edu.au>]

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 <ro...@anu.edu.au> 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