harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 07 Dec 2006 04:13:17 GMT
Xiao-Feng Li wrote:

>> 2)  I have to use 3 params for fast path helper because slow helper
>> (gc_heap_slot_write_ref) requires 3 params.
> 
> Mikhail, we need a simpler helper. The current helper is used for a
> full barrier including both the fast-path and slow-path. It's
> undesirable. 

Excuse me if I'm missing some details here, but surely the number of 
parameters to the write barrier helper is unimportant (well, within 
limits) ?  Since the helper (by definition) is inlined, there is no real 
parameter passing going on, and unused parameters will simply be 
optimized away.

And given that the fast-path, by definition is fast, then surely calling 
  it when you know that the slow-path will be taken is virtually zero 
overhead ?

I was also under the impression that Moxie required the inlined helpers, 
and since Moxie uses MMTk, won't it need the additional parameters ?

 >            And the API gc_heap_slot_write_ref() is called sometimes
> by VM even for a non-generational GC. So its implementation is not
> efficient. I'd suggest to have a simpler helper for slow-path-only:
> gc_slot_remember( Managed_Object_Handle *p_slot,
> Managed_Object_Handle p_target ). It is not a barrier, but only
> remember the slot. For GCv5, the concrete code should look like:
 >
> void gc_slot_rem( Managed_Object_Handle *p_slot,
> Managed_Object_Handle p_target )
> {
>  Mutator *mutator = (Mutator *)gc_get_tls();
>  mutator_remset_add_entry(mutator, (Partial_Reveal_Object**)p_slot);
> }
> 
> How do you think? Thanks.
> 
> This slow path needs actually only one parameter, but initially it's
> ok to give two for assertion check to make sure it should be
> remembered.
> 
> Thanks,
> xiaofeng
> 
>> On 12/6/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>> >
>> > On 12/6/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>> > > Today helpers are inlined only by SD2_OPT JIT. We can add helpers
>> > inlining
>> > > to SD1_OPT too, but helpers classes are initialized only from VMStart
>> > class
>> > > - so there will be ~1k methods compiled by SD1_OPT without helpers
>> > inlined
>> > > and we will have a problem to differentiate them.
>> >
>> > Probably we can introduce some annotations to guide the compiler for
>> > branch scheduling (and probably for some other scenarios as well, such
>> > as dead object for GC).  Of course that will not be prioritized until
>> > some evidence shows the importance.
>> >
>> > Thanks,
>> > xiaofeng
>> >
>> > > On 06 Dec 2006 16:52:12 +0600, Egor Pasko <egor.pasko@gmail.com>

>> wrote:
>> > > >
>> > > > On the 0x237 day of Apache Harmony Mikhail Fursov wrote:
>> > > > > On 06 Dec 2006 13:13:51 +0600, Egor Pasko <egor.pasko@gmail.com>
>> > wrote:
>> > > > > >
>> > > > > > Jitrino.OPT relies on edge profile. The most probable edges
are
>> > > > > > fallthrough.
>> > > > >
>> > > > > The only problem  here is that vmhelpers are never recompiled
>> > and  their
>> > > > IR
>> > > > > is estimated with heuristic based profiler. So, as JIT developer,
>> > I'm
>> > > > not
>> > > > > sure if a branch in Java code will be layouted as fallthrough

>> or as
>> > > > jump.
>> > > >
>> > > > That's interesting! I see no serious reasons that can stop us from
>> > > > profiling VM helpers. Just need the right .emconf. Or am I missing
>> > > > something?
>> > > >
>> > > > --
>> > > > Egor Pasko
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Mikhail Fursov
>> > >
>> > >
>> >
>>
>>
>>
>> -- 
>> Mikhail Fursov
>>
>>


-- 
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

Mime
View raw message