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

[Aleksey Shipilev]

On Tue, 25 Apr 2023 12:28:23 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

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

Thanks for the explanation. If the `NativeAccess` hack fails for ZGC, then I have to assume it might fail for other GCs too, and therefore using it, even though it uses a "generic" GC API, is still a hack. I reverted the last commit, so we now have the explicit barrier for Shenandoah there, pretty much like we used to have before Loom integration.

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

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