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 Fri, 08 Dec 2006 00:26:21 GMT
On 12/7/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> On 12/7/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > 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.
> >
>
> Xiao-Feng,
> I propose to make 3args version initially - it require less changes in code.
> I think I finish this version in a hour.
> The only issue: a lot of problems with magics and unmanaged objects were
> fixed in monenter patch that is not in SVN and I'm going to post it only
> tomorrow after passing all of the tests on Linux.
>
> So my proposal is to post temporary patch with WB helper inlined and update
> it after monenter is committed.
> Is it Ok if I send WB patch to JIRA tomorrow? This will give me more time to
> check it with gcv4, right now I have the code but have not run any tests.

Mikhail, three args are ok for experiment. But please use a different
name for the native vm helper, such as gc_heap_slot_write_barrier. The
original gc_heap_slot_write_ref is shared by non-generational GC,
which is not intended for slot remembering.

Btw, it's strange to me you are still talking about GCv4. Is it a typo?

Thanks,
xiaofeng

> --
> Mikhail Fursov
>
>

Mime
View raw message