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][sablevm] Desing of Class Unloading Support
Date Wed, 01 Nov 2006 01:11:02 GMT
On 10/31/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> On 10/31/06, Etienne Gagnon <egagnon@sablevm.org > wrote:
> > >Yet:
> >
> > >1- You do need pinning, so you rule out some of the simplest GCs (e.g.
> > >simple, non-generational copying without pinning.)  [Apparently, for
> > >some very large heaps, simple copying a can be quite difficult to beat,
> > >efficiency wise, if you believe some relatively recent JikesRVM related
> > >paper...]
> Yes, this was one of my  concerns about the vtable object approach. This
> is
> limiting, but this is one specific GC requirement. (Maybe for GC's that
> don't support pinning, the JIT can compare object->vtable->class for
> guarded
> devirtiualization, or even not do guarded devirtualization, sort of
> support
> the GC in downlevel mode). For the refcounting method we need to hand off
> between  GC and VM before and after processing weak references, update the
> generational or semispace related CL flags, and also use the GC to undo or
> rescue CL instances that may come alive due to the generational flag
> processing.

> >2- You do have overhead even on minor collections.  With my approach,
> > >you could limit the (quite similar to yours, if you put a
> > >class-loader/NULL pointer in the vtable) overhead only to selected GC
> > >cycles.
> I think the main advantage of the vtable object approach is that it is
> somewhat elegant and natural, if one can get past the idea of non C
> vtables
> :-). Special casing to avoid object->vtable scans during minor collections
> etc. just breaks that. Relying on GC all the way forces a class unloading
> overhead to every GC cycle( even for the young generation collections ).
> There is also a space overhead that I can't really estimate( proportional
> to
> class ....etc. etc.). As I understood it, there is no impact on MMTk based
> GC's, but I may be wrong.

Actually Robin Garner in the other class unloading thread ([drlvm] classs
unloading support) said minor mods to MMTk might be required.

If class unloading is done at specific moments only, the refcounting
> approach does not add a perf overhead to each GC cycle, there is no heap
> overhead of the method either. But the former implies yet another
> secondary heuristic to optimally choose the class unloading triggers, this
> depends on the application profile and is not really once an hour/day etc.
> My guess( humbly ) would be that the refcounting method "may" be somewhat
> more time/space efficient, but that's probably not the only issue. There
> is
> the issue of implementation correctness, existing code, etc. And I don't
> know what's the best way to go to the next step.
> A suggestion could be to take Harmony-2000, review it, put it in a branch,
> tune and test it , wait for GCV5 to start supporting pinning, try with
> MMTk,
> and then integrate.

I can't really visualize the changes to 40 files by looking at a diff file.
It seems inefficient for all of us to battle applying the patch simply to be
able to look at the code and set break points with the debugger.

If we do this, the refcounting approach would be a
> fallback for DRLVM.
> We need to decide on next steps, we cannot debate the algorithm forever
> :-)

Weldon Washburn
Intel Enterprise Solutions Software Division

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