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 07:40:14 GMT
Xiao-Feng Li wrote:
> On 12/7/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>> 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.
> 
> Robin, thanks. Yes, for the Java helper, it doesn't matter to have
> more parameters.
> 
> But the parameters here are those for the native function invocation
> that does the real remembering. It is not inlined, so the parameter
> count might have impact on performance, but we don't know without real
> experiment.

But by definition, the slow-path helper is slow.  I would be very 
surprised if extra parameters had any significant impact on speed, 
particularly with the simple boundary-crossing barrier.

> 
> The other reason for a new native write barrier interface is, the
> original one is called by VM even with non-generational GC. It's
> undesirable to have a check in the native function body about whether
> it's generational GC or not. We can change either the VM body or only
> the GC side. So my suggestion is to change the GC side.

Again, I would have thought this was by far the least common case - the 
mutator modifies pointers far more than the VM.

I would think that rather than implement the whole thing and measure, if 
you added some simple counters of:
- fast path invocation
- slow path invocation
- VM invocation

that the relative numbers would give enough information to inform the 
decision.

> Thanks,
> xiaofeng

cheers,
robin

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


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

Mime
View raw message