RFR: Consolidate assembly write barriers

Roman Kennke rkennke at redhat.com
Mon Jul 9 18:08:30 UTC 2018


Am 09.07.2018 um 19:08 schrieb Aleksey Shipilev:
> On 07/09/2018 06:50 PM, Roman Kennke wrote:
>> We have two versions of write-barrier-implementations in assembly code:
>> one for interpreter and one for C1 (and C2, but this is going away with
>> previous RFR). The reason why we had this was that the stub that is used
>> by the 2nd version could previously not be generated before the
>> interpreter. However, with recent enhancements by the modularization of
>> barriers efforts, this is fixed, and we can now use the same
>> write-barrier-assembly everywhere.
>>
>> http://cr.openjdk.java.net/~rkennke/shenandoahwb/webrev.00/
> 
> *) Can you remove Membar::LoadLoad in aarch64 separately? It should be backported.
> 
>  277   __ membar(Assembler::LoadLoad);

Yeah, will do. See other patch.

> *) Trying to understand the constraints: do we not need saving callee registers before calling into
> SBSA::shenandoah_wb() from interpreter now? It is confusing, because SBSA::storeval_barrier_impl
> still saves the registers with comment:
> 
>     // The set of registers to be saved+restored is the same as in the write-barrier above.
>     // Those are the commonly used registers in the interpreter.

The write-barrier goes through the stub, which saves the registers.

Remaining patch:
http://cr.openjdk.java.net/~rkennke/shenandoahwb/webrev.01/

Roman



More information about the shenandoah-dev mailing list