RFR: Consolidate assembly write barriers

Aleksey Shipilev shade at redhat.com
Mon Jul 9 17:08:54 UTC 2018


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

*) 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.

Thanks,
-Aleksey



More information about the shenandoah-dev mailing list