RFR: JDK-8213199: GC abstraction for Assembler::needs_explicit_null_check()

[Roman Kennke]

Hi Erik,

right. Fixed this, and what what Kim mentioned plus a missing include:

Incremental:
http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.01.diff/
Full:
http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.01/

Ok now?

Roman

> Hi Roman,
> 
> Pretty sure this will break zero.
> 
> Thanks,
> /Erik
> 
>> On 31 Oct 2018, at 18:27, Roman Kennke <rkennke at redhat.com> wrote:
>>
>> GCs (like Shenandoah) may emit additional loads or stores. In the case
>> of Shenandoah, we emit forward pointer loads from offset -8. Those
>> accesses don't match the pattern currently checked in
>> Assembler::needs_explicit_null_check() which means that explicit null
>> checks would be emitted for forwarding pointer loads. But we don't want
>> that because we know that the base object cannot be NULL (everything
>> else would be an error).
>>
>> I'm proposing to put an abstraction in needs_explicit_null_check(). I am
>> basically trying to solve the mess that we have in Shenandoah in this place:
>>
>> https://builds.shipilev.net/patch-openjdk-shenandoah-jdk-only-shared/latest/src/hotspot/share/asm/assembler.cpp.sdiff.html
>>
>> After experimenting back-and-forth with a bunch of approaches, it seems
>> to be most useful and least intrusive to simply put the whole method
>> under GC's control by moving its body into BarrierSetAssembler:
>>
>> http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.00/src/hotspot/share/gc/shared/barrierSetAssembler.cpp.html
>>
>> The corresponding Shenandoah implementation for x86 would then look like
>> this:
>>
>> http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.shenandoah/src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp.sdiff.html
>>
>> As an additional bonus, this approach provides not only a GC-abstraction
>> but also implicitely a cpu-abstraction, which helps to avoid the #ifdef
>> mess that we made in that method.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8213199
>> Full webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.00/
>>
>> Testing: passes hotspot/jtreg:tier3 on x86/fastdebug
>>
>> Can I please get reviews on this? Also, any suggestions for improvement
>> are very welcome!
>>
>> Thanks,
>> Roman
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181031/d98e17fc/signature.asc>