harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm][sablevm] Desing of Class Unloading Support
Date Tue, 31 Oct 2006 22:54:23 GMT
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,
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 :-)

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