harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Wed, 01 Nov 2006 04:59:58 GMT
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 <robin.garner@anu.edu.au> wrote:
>
> 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.
>
> cheers,
> Robin
>

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