harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Class unloading support
Date Fri, 10 Nov 2006 15:51:47 GMT
Sorry for the confusion.  We are getting ourselves all tangled up with
subconversations in this thread.  There have been 90+ replies to the
original posting.

No patch containing class unloading will be committed until Harmony has a
design and the design has been implemented.

What is being discussed is a patch that cleans up the malloc/free of C
structs that are currently used for class loading.  I have looked at the
proposed patch.  It looks to have low impact on stability.  It contains no
class unloading code.  Its not urgent to apply this patch.  I will hold off
doing anything until the confusion clears.  It might even be better to open
a new JIRA titled something like, "classloader malloc/free cleanup".  Note
there are currently 12 files attached to HARMONY-2000.

The patch at issue was split out of the original class unloading patch to
isolate independent problems.


On 11/10/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
> 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
> >>
> >>
> >
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

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