harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Garner" <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Thu, 07 Dec 2006 11:43:27 GMT
> On 12/7/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>> Xiao-Feng Li wrote:
>> > On 12/7/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>> >> Xiao-Feng Li wrote:
>> >>
>> >> >> 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.
>> >>
>> >> Excuse me if I'm missing some details here, but surely the number of
>> >> parameters to the write barrier helper is unimportant (well, within
>> >> limits) ?  Since the helper (by definition) is inlined, there is no
>> real
>> >> parameter passing going on, and unused parameters will simply be
>> >> optimized away.
>> >
>> > Robin, thanks. Yes, for the Java helper, it doesn't matter to have
>> > more parameters.
>> >
>> > But the parameters here are those for the native function invocation
>> > that does the real remembering. It is not inlined, so the parameter
>> > count might have impact on performance, but we don't know without real
>> > experiment.
>>
>> But by definition, the slow-path helper is slow.  I would be very
>> surprised if extra parameters had any significant impact on speed,
>> particularly with the simple boundary-crossing barrier.
>>
>> >
>> > The other reason for a new native write barrier interface is, the
>> > original one is called by VM even with non-generational GC. It's
>> > undesirable to have a check in the native function body about whether
>> > it's generational GC or not. We can change either the VM body or only
>> > the GC side. So my suggestion is to change the GC side.
>>
>> Again, I would have thought this was by far the least common case - the
>> mutator modifies pointers far more than the VM.
>>
>> I would think that rather than implement the whole thing and measure, if
>> you added some simple counters of:
>> - fast path invocation
>> - slow path invocation
>> - VM invocation
>
> Robin, I guess we have some miscommunication.
>
> The problem here is not about Java helper parameters. This native VM
> helper function is not a real write barrier. It is only a function to
> do the real remembering. It doesn't make sense for it to take some
> useless parameters. This function can be invoked by other write
> barrier functions (native or Java). For example,
> gc_heap_slot_write_ref can call it when the GC is generational.

So in standard GC terminology, this is the API for adding a reference to
the remembered set ?  I guess I'm having difficulty understanding why
anything except the write barrier would want to add an entry to the
remset.

> We are not talking about a generic write barrier API, because this
> function is not a write barrier itself. I know the ratio of slow path
> is much lower than the fast path, but that's not the reason to put
> something useless in the VM helper.
>
> If we want other Java write barrier functionality that the current
> design doesn't support, we can modify the Java helper code later on.
> But that's another thing, different from the VM native helper.

OK, I think the term "helper" is being overloaded here ?

> Finally, the Java helper code is specific to the GC implementation,
> hence put into the specific GC directory. It doesn't impact other GC
> to have other Java helper code. Now what Mikhail is building is an
> inlining infrastructure that will easily adapt to different helpers.

Sure, the Java helper code is GC-specific, but the interface should be
common across all GCs.  We're on the same page here, aren't we ?

> Thanks,
> xiaofeng
>

cheers,
Robin


Mime
View raw message