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
Date Tue, 31 Oct 2006 16:13:21 GMT
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

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.

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

Weldon Washburn
Intel Enterprise Solutions Software Division

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