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 Fri, 03 Nov 2006 13:33:25 GMT
I've introduced class unloading test into harmony-2000 attachments:
Test_unloading_native_lib.zip. This test is drlvm class unloading
implementation specific.

Aleksey.


On 11/3/06, Aleksey Ignatenko <aleksey.ignatenko@gmail.com> wrote:
>
> Weldon,
> >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.
> Vtables are not affected in native resource cleanup patch (no change from
> c struct to object).
> GCV4: There is some code cleanup and native resource cleaning in gcv4. The
> same will be done for gc_gen and gc_cc by GC people with separate JIRA,
> becuse it could affect some performance problems.
>
> I have updated patches to the final versions:
> native_sources_cleanup_upd.patch, auto_unloading_upd.patch. So, I suppose
> native_sources_cleanup_upd.patch is ready for comit.
> Aleksey.
>
>
>
>  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
> >
> >
>

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