On 12/7/06, Xiao-Feng Li <[EMAIL PROTECTED]> 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 Fursov
