Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [drlvm][sablevm] Desing of Class Unloading Support
Date: 01 Nov 2006 10:37:41 +0600
Lines: 61
Message-ID: <uac3baiju.fsf@gmail.com>
References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com>
 <4544EFB8.4060704@sablevm.org>
 <12385bbd0610291051l4a23f64h8f726e1103a4bc59@mail.gmail.com>
 <45450269.4020503@sablevm.org>
 <4dd1f3f00610291553x5d7b2bc9seb2c419bd4fa54ff@mail.gmail.com>
 <45461100.50304@sablevm.org>
 <51d555c70610301610qf3f2c67g35899c9bbc6a4d3d@mail.gmail.com>
 <4547A6E4.5080903@sablevm.org>
 <12385bbd0610311259m1012cdadl4f9452dc336dbac7@mail.gmail.com>
 <4547BC2B.2080600@sablevm.org>
 <51d555c70610311454s24d2089cx7eeb9af17d7ebfaf@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Sender: news <news@sea.gmane.org>

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