harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 07 Dec 2006 03:55:00 GMT
Mikhail, thanks.

> I almost finished WB helper inlining support in JIT, but need some
> additional instructions.
>
> 1) Jitrino's HIR uses several instruction with Store_WriteBarrier modifier:
> Op_TauStInd, Op_StInd, Op_TauStStatic, Op_TauStElem, Op_TauStField and
> Tau_StRef, but only the last leads to WB helper call generation in HIR2LIR
> selector. Why?

Op_TauStInd and Tau_StRef are the same thing but the latter for write
barrier generation, the other doesn't. They are switched by the need
of write barrier.

Op_TauStStatic is enumerated in DRLVM. It would be good to have a
runtime option to specify write barrier generation or not. It's not
urgent anyway.

Op_TauStElem and Op_TauStField are under !expandMemoryAddress branch,
it looks like no need for barrier.

Op_StInd: don't know this one.

These might not be the best design. You may give good suggestions.

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

Mime
View raw message