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 Fri, 03 Nov 2006 08:34:41 GMT
On the 0x214 day of Apache Harmony Aleksey Ignatenko wrote:
> Egor,
> 
> Vtable objects pinning is required not only by JIT, this is also required by
> GC, which relies on that VTables are non movable. So this not a way to
> disable guarded devirtualization. Pinning is required anyway.

Sorry, but I am not aware of places, where pinning is required other
than for JIT. If you menttion one or two, that would be great for
understanding and the next step to beat my ignorance in this subject :)

> On 01 Nov 2006 10:37:41 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> >
> > 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
> >
> >

-- 
Egor Pasko


Mime
View raw message