harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][sablevm] Desing of Class Unloading Support
Date Wed, 01 Nov 2006 04:37:41 GMT
On the 0x214 day of Apache Harmony Rana Dasgupta 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.
> 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,

an alternative: JIT can disable guarded devirtualization via an
option. Commit the unloading, use/tune GCV5 with that opion until it
supports pinning. No branch required.

> tune and test it , wait for GCV5 to start supporting pinning, try with MMTk,
> and then integrate. 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 :-)

-- 
Egor Pasko, Intel Managed Runtime Division


Mime
View raw message