Integrated: 8369946: Bytecode rewriting causes Java heap corruption on PPC

Martin Doerr mdoerr at openjdk.org
Wed Oct 22 08:37:58 UTC 2025


On Fri, 17 Oct 2025 12:13:52 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.

This pull request has now been integrated.

Changeset: 6bf3581b
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6bf3581bbacc2ed8f6411d23a5ab332376c53c87
Stats:     36 lines in 3 files changed: 12 ins; 4 del; 20 mod

8369946: Bytecode rewriting causes Java heap corruption on PPC

Reviewed-by: rrich, dbriemann

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

PR: https://git.openjdk.org/jdk/pull/27867


More information about the hotspot-compiler-dev mailing list