Weldon Washburn wrote:
On 10/30/06, Robin Garner <[EMAIL PROTECTED]> wrote:
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.
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.
cheers,
Robin
