harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] Class unloading support
Date Fri, 10 Nov 2006 15:17:20 GMT
Hang on - we aren't going to consider this patch quite yet, are we?  We 
have a very active and fruitful discussion going on regarding alternate 
approaches?

geir


Aleksey Ignatenko wrote:
> Weldon, I have attached updated patch to H-2000:
> cleanup_sources_1558_merged.patch.
> Please, see comments.
> 
> Aleksey.
> 
> 
> On 11/10/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>>
>> Aleksey,
>> I tried to apply native_sources_cleanup_upd.patch.  svn HEAD has changed
>> and
>> the patch no longer works.  Part of the problem is that JIRA 1558 has 
>> been
>> committed.  In addition to the below issues, I posted comments to
>> JIRA HARMONY-2000.
>>
>>
>> On 11/2/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>> >
>> > Aleksey,
>> >
>> > Excellent step forward -- breaking the patch into two pieces.   This
>> made
>> > the patch(es) much more readable.
>> >
>> > I glanced at native_sources_cleanup.patch.  It looks like code for
>> > alloc/dealloc vtables and jitted code blocks.  The original patch made
>> > vtables into objects.  Will native_sources_cleanup need to change if
>> vtables
>> > are normal C structs instead?  Also, I see reference to path
>> .../gcv4/...  I
>> > guess this will need to change to support gc_gen and gc_cc.
>> >
>> > Once you get native_sources_cleanup.patch in good shape, I have no
>> problem
>> > committing it.
>> >
>> > If there is no other debate on class unloading design, I will call 
>> for a
>> > vote in a seperate email.
>> >
>> >
>> >
>> > On 11/2/06, Aleksey Ignatenko <aleksey.ignatenko@gmail.com> wrote:
>> > >
>> > > 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 <aleksey.ignatenko@gmail.com> 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 < aleksey.ignatenko@gmail.com>

>> 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.Classesand
>> > > > > 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.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
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Weldon Washburn
>> > Intel Enterprise Solutions Software Division
>> >
>>
>>
>>
>> -- 
>> Weldon Washburn
>> Intel Enterprise Solutions Software Division
>>
>>
> 

Mime
View raw message