Weldon Washburn wrote:
On 10/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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. 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
