RFR: Check BS type in immByteMapBase predicate

[Roman Kennke]

Am 05.12.2017 um 11:55 schrieb Aleksey Shipilev:
> 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?

Not in Shenandoah case. But it happens to match a constant to whatever 
'pointer' it finds in memory at the location, that's where the myterious 
0x7000 and similar values have come from.

One thing that is not 100% clear to me is if this can match a constant 
that happens to have the same address as the byte_map_base, and what 
would happen if that is the case.

>   What would happen if code uses that
> operand, but new predicate mismatches it (e.g. in Shenandoah)?
It cannot be used in Shenandoah because we don't  use the 
CardTableModRefBS. Checking for the BS type seems the safest way to 
prevent the bug.

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

Ok.