harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm] Class unloading support
Date Tue, 31 Oct 2006 07:14:55 GMT
Weldon Washburn wrote:
> On 10/27/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>> Weldon Washburn wrote:
>> > Steve Blackburn was in Portland Oregon today.  I mentioned the idea of
>> > adding a  reference pointer from object to its j.l.Class instance.  
>> MMTk
>> > was
>> > not designed with this idea in mind.  It looks like you will need to 
>> fix
>> > this part of MMTk and maintain it yourself.  Steve did not seem 
>> thrilled
>> at
>> > adding this support to MMTk code base.

Actually I think the answer may have been a little garbled along the way 
here: MMTk is not a memory manager *for* Java, it is simply a memory 
manager.  We have been careful to eliminate language-specific features 
in the heap that it manages.  MMTk has been used to manage C# (in the 
Rotor VM) and was being incorporated into a Haskell runtime until I ran 
out of time.

Therefore, MMTk knows nothing about the concept of class unloading, or 

>> How does MMTk support class unloading then?
> MMTk has no special support for class unloading.  This may have 
> something to
> do with the entire system being written in Java thus class unloading come
> along for free.  If there needs to be a modification to support special 
> case
> objects in DRLVM, someone will need to fixup MMTk and provide onging
> support of this patch in Harmony.  I have zero idea how big this effort
> would be.   It would also be good to hear what the impact will be on GCV5.

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.

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).


View raw message