RFR: Check BS type in immByteMapBase predicate

Aleksey Shipilev shade at redhat.com
Tue Dec 5 10:55:50 UTC 2017


On 12/05/2017 11:50 AM, Roman Kennke wrote:
> In aarch64, we have an instruction in aarch64.ad that blindly casts the current BarrierSet to
> CardTableModRefBS, and uses this in the predicate to generate an immediate load if the operand
> matches the byte_map_base of the CTMRBS. However, when used with a GC that doesn't derive its BS
> from the CTMRBS, it reads some random thrash and inserts the special instruction sequence
> (adrp+movk) on immediate loads that happen to match whatever is in the imaginary byte_map_base...
> This eventually leads to corrupted heap. The fix is to check the BS type in the predicate too:
> 
> 
> http://cr.openjdk.java.net/~rkennke/aarch64-ctmrbs/webrev.00/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html

Um. Does this mean something is using immByteMapBase() operand? What would happen if code uses that
operand, but new predicate mismatches it (e.g. in Shenandoah)?

> I intend to push backports of this to 9 and 8 too. Do I need extra reviews for those?

Since this is not 9- or 8u-specific, I think you just push to sh/jdk10, and then regular backports
process handles the propagation to sh/jdk9 and sh/jdk10.

Thanks,
-Aleksey




More information about the shenandoah-dev mailing list