Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com
 designates 64.233.184.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=TLL6BHZXwgdG3qd7giQ6eiCYhQPTxiKDSCqjfCTDDDQycB3dSXLiFXe+FZcFLu9Bd3uufVZRXBTD8Yl5yZ/0pma2DYRGo+YNwYyOtPH5PVrf0pi8YF1HL92HJC3SeEUHbaS81BTxx4aM0Vpp+rNvRY6h0iEYc8p4D8ATVl2YcaI=
Message-ID: <9623c9a50612071626r3a160004x81592cb3fb70deed@mail.gmail.com>
Date: Fri, 8 Dec 2006 08:26:21 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [DRLVM][Helper inlining] GC write barrier inline?
In-Reply-To: <bc79dd600612070630s7ce6bb7dhc599d6f9bc5f44b5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9623c9a50611281757h3b8923d2o52e54adc857c073c@mail.gmail.com>
	 <51d555c70612050857p18dc73e6q3bc88585b077e2d@mail.gmail.com>
	 <uirgpjy34.fsf@gmail.com>
	 <bc79dd600612060230j1233d56fnad08cb68e1a62a92@mail.gmail.com>
	 <uac21jnz7.fsf@gmail.com>
	 <bc79dd600612060255w734edff4ib014888151d7f876@mail.gmail.com>
	 <9623c9a50612060409s7e936f0dv1692502dc97cbe75@mail.gmail.com>
	 <bc79dd600612060541o487aa01fo4ea004b61b38de7f@mail.gmail.com>
	 <9623c9a50612061955j307e8aaem71d54898313aeada@mail.gmail.com>
	 <bc79dd600612070630s7ce6bb7dhc599d6f9bc5f44b5@mail.gmail.com>

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