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