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 Tue, 07 Nov 2006 08:35:55 GMT
On the 0x217 day of Apache Harmony Ivan Volosyuk wrote:
> In current GCv4.1 implementation there is an assumption that vtables
> will not move. It is used in compaction algorithm. Strictly speaking,
> the only thing I need is to distinguish objects and vtables during
> allocation. If so, one of GC algorithms may treat vtables as pinned
> objects, while another could make use of the ability to move the
> vtables. 

Ivan, thank you for making it clear!

> I already have one idea how to benefit from movable vtables.

in GCV4.1? :)

> --
> Ivan
> 
> On 03 Nov 2006 14:34:41 +0600, Egor Pasko <egor.pasko@gmail.com> wrote:
> > 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


Mime
View raw message