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