Weldon,
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.
I agree with Robin:
Simple. Keep a list or table of these objects as part of the root set.
Enumerate it optionally depending on a command line option.
Details: you can see from Harmony-2000 patch, that this is done for
Bootstrap classes already. If you look at root_set_enum_common.cpp (with the
patch applied) vm_enumerate_static_fields() function, there is line:
if (cl->IsBootstrap())
{
vm_enumerate_jlc(c);
if (c->vtable)
vm_enumerate_root_reference((void**)&c->vtObj,
FALSE);
}
else
{
vm_enumerate_jlc(c, true/*weak*/);
}
You can see, that there are strong roots to Bootstrap j.l.Classes and their
VTable objects. So I suppose, that it would be very simple to propogate
strong roots to all other classes (not only Bootstrap), something like:
if (cl->IsBootstrap() *&&
env->b_VTable_trace_is_not_supported_by_GC*)
{
vm_enumerate_jlc(c);
if (c->vtable)
vm_enumerate_root_reference((void**)&c->vtObj,
FALSE);
}
where *b_VTable_trace_is_not_supported_by_GC *is flag which is set according
to used GC. This will force switching off any class unloading support.
Aleksey.
On 11/1/06, Robin Garner <[EMAIL PROTECTED]> wrote:
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
