RFR: 8306734: Shenandoah: Missing barriers on deoptimization path [v2]

[Erik Österlund]

On Tue, 25 Apr 2023 12:12:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> AFAICS, Loom integration ([JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161)) moved the Shenandoah block `StackValue::create_stack_value` that we added to avoid exposing bad oops during the deopt ([JDK-8224522](https://bugs.openjdk.org/browse/JDK-8224522)). I think that was done to avoid interaction with barrier healing acting on derived pointer bases (?), so it employed the `NativeAccess::load_oop` trick to still call into GC barriers without healing. Then, the refactoring for ZGC ([JDK-8296875](https://bugs.openjdk.org/browse/JDK-8296875)) redid these paths, but dropped the `NativeAccess::load_oop` completely, which exposed Shenandoah to a missing barrier.
>> 
>> Serial, Parallel, G1 are not affected by this, because they do not need load-barriers. Not sure why ZGC is not affected by this, but probably because it does the barrier injection in another place (see [JDK-8224675](https://bugs.openjdk.org/browse/JDK-8224675)).
>> 
>> There are two ways to fix it: with the Shenandoah-specific barrier injection, or reinstating the `NativeAccess::load_oop` trick Loom integration originally did. I preferred to keep the fix GC-agnostic and reinstate the `NA::load_oop`. AFAIU, this would be innocuous for other GCs, ZGC included.
>> 
>> Attention: @fisk.
>> 
>> Additional testing:
>>  - [x] Reproducer from the bug is no longer failing; used to fail 1/2 times on 3 platforms; does not fail after 50 tries
>>  - [x] Linux x86_64 fastdebug `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 fastdebug `hotspot_gc_shenandoah`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Replace Shenandoah-specific code with the old barrier load trick
>  - Merge branch 'master' into JDK-8306734-shenandoah-deopt-barriers
>  - Work

Ah. Apologies for removing your barriers - I forgot you about the safepoint between load and load barrier problem, requiring load barriers even on the stack. As mentioned in the description, avoiding these kinds of issues was indeed why we moved our barrier expansion to the assembly stage in ZGC. And indeed, that's why ZGC does not have any such barriers.
Unfortunately, the NativeAccess hack will not work for generational ZGC - it is going to crash immediately. So I preferred the more explicit and possibly less pretty conditional shenandoah code. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13613#issuecomment-1521705406