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 Wed, 01 Nov 2006 02:27:30 GMT
Weldon Washburn wrote:
> On 10/30/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>> 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
>> java.lang.Class.
>> >> 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.
> Robin, it would be great if you can get MMTk to support this class 
> unloading
> effort.  My main concern is the ongoing maintenance of MMTk class unloading
> support.

I haven't seen any proposal that requires MMTk to be modified, so it's a 
moot point at the moment.

> A question for all involved.  Is it possible to somehow make it appear that
> the new objects related to unloading  (VTable, ClassLoader, etc)  are 
> always
> reachable and thus never collected?  I am trying to figure out a way to 
> make
> integration of class unloading independent of correct support inside the GC
> and JIT.  This option could be a command line switch or compile time 
> option.

Simple.  Keep a list or table of these objects as part of the root set. 
  Enumerate it optionally depending on a command line option.


View raw message