RFR: JDK-8213199: GC abstraction for Assembler::needs_explicit_null_check()
rkennke at redhat.com
Wed Oct 31 22:14:58 UTC 2018
right. Fixed this, and what what Kim mentioned plus a missing include:
> Hi Roman,
> Pretty sure this will break zero.
>> 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:
>> 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:
>> The corresponding Shenandoah implementation for x86 would then look like
>> 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.
>> Full webrev:
>> Testing: passes hotspot/jtreg:tier3 on x86/fastdebug
>> Can I please get reviews on this? Also, any suggestions for improvement
>> are very welcome!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev