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