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

Martin Doerr mdoerr at openjdk.org
Tue Oct 21 08:57:41 UTC 2025


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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27867/files
  - new: https://git.openjdk.org/jdk/pull/27867/files/138df669..773b82f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27867&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27867&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27867/head:pull/27867

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


More information about the hotspot-compiler-dev mailing list