harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [drlvm][sablevm] Desing of Class Unloading Support
Date Wed, 01 Nov 2006 05:17:15 GMT
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.

Aleksey.


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
>
>

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