harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 07 Dec 2006 14:30:40 GMT
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
> > 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.

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 Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message