RFR: 8369946: Bytecode rewriting causes Java heap corruption on PPC [v2]

[Martin Doerr]

On Tue, 21 Oct 2025 08:57:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Like the aarch64 fix (https://github.com/openjdk/jdk/pull/27748).
>> PPC64 has additional requirements:
>> - It implements `fast_invokevfinal` which uses `ResolvedMethodEntry`.
>> - Speculative loads need to get prevented by memory barrier instructions (even on control dependent paths).
>> 
>> I've refactored `load_field_entry` and `load_method_entry` into a common function and added support for rewritten "fast" Bytecodes. I'm using `isync` instructions because we already have a control dependency (via Bytecode dispatch).
>> 
>> The `isync` instruction is relatively cheap in comparison to other memory barriers, but still introduces some performance loss. SPEC jvm98 with -Xint shows about 5% regression in `compress` sub-benchmark. The other sub-benchmarks are not significantly impacted. However, switching off `RewriteBytecodes` would cause a much higher performance loss.
>> 
>> Note: I had also ported the `verify_field_offset` check and used it in the fastdebug and product build for testing, but couldn't catch any issue. Not included in this PR. I'm not planning to contribute it.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment.
>   
>   Co-authored-by: Richard Reingruber <richard.reingruber at sap.com>

Thanks for the reviews! I'll start working on backports.

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

PR Comment: https://git.openjdk.org/jdk/pull/27867#issuecomment-3431092379