Hi, everyone.
I've splitted Harmony-2000 (see details:
http://issues.apache.org/jira/browse/HARMONY-2000) patch with automatic
class unloading implementation into 2 independent parts:
1. cleaning native resources (native_sources_cleanup.patch).
2. automatic unloading design implementation (auto_unloading.patch).
The first part is independent for all class unloading designs and could be
commited. The second part is class unloading design implementation (the best
class unloading approach is discussed now).
I propose to commit native_sources_cleanup.patch and continue class
unloading development with minimal requirements on drlvm.
Aleksey.
On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
Oops, sorry, misprinted in my suggestion:
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);
}
Aleksey.
On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>
> 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.Classinstance.
> > >> >> 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
> >
>
>
