RFR: 8369506: Bytecode rewriting causes Java heap corruption on AArch64
    Andrew Haley 
    aph at openjdk.org
       
    Wed Oct 15 13:33:44 UTC 2025
    
    
  
On Fri, 10 Oct 2025 16:21:17 GMT, Justin King <jcking at openjdk.org> wrote:
> Fix JDK-8369506 by adding `STLR` when updating the bytecode. Additionally I added a quick debug only check which verifies the field offset we get from `ResolvedFieldEntry` in `TemplateTable::fast_*` will not clobber the header or Klass pointer. The added `STLR`, a long with the already existing `DMB ISHLD` in `InterpreterMacroAssembler::load_field_entry`, guarantees that the fully filled out `ResolvedFieldEntry` is observable if the patched bytecode is observable. We do not need to add `LDAR` for bytecode loading or `LDAR` in `TemplateTable::fast_*` for that reason. If another observer happens to observe a `0` field offset, its guaranteed then that they will also observe the non-patched bytecode which will ultimately end up doing the resolution again, which is okay.
> Fix JDK-8369506 by adding `STLR` when updating the bytecode. Additionally I added a quick debug only check which verifies the field offset we get from `ResolvedFieldEntry` in `TemplateTable::fast_*` will not clobber the header or Klass pointer. The added `STLR` guarantees that the fully filled out `ResolvedFieldEntry` is observable if the patched bytecode is observable. We do not need to add `LDAR` for bytecode loading or `LDAR` in `TemplateTable::fast_*` for that reason.
How does this follow? We need some sort of happens-before relationship on the reader side to make sure that the resolved field entry is observed. I guess this PR relies on a control dependency between reading the patched bytecode and executing the code that reads the resolved field entry.
src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 238:
> 236:   // Patch the bytecode using STLR, this is required so that the last STLR used in
> 237:   // ResolvedFieldEntry::fill_in is obsevable before the patched bytecode. If it is not,
> 238:   // TemplateTable::fast_* will observe an unresolved ResolvedFieldEntry and corrupt the Java heap.
Suggestion:
  // Patch the bytecode using STLR so that the last STLR used in
  // ResolvedFieldEntry::fill_in is observed before the patched bytecode.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27748#issuecomment-3393652648
PR Review Comment: https://git.openjdk.org/jdk/pull/27748#discussion_r2422652088
    
    
More information about the hotspot-compiler-dev
mailing list