RFR: 8369506: Bytecode rewriting causes Java heap corruption on AArch64

[Aleksey Shipilev]

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.

Yes, I agree this is sufficient. I have only cosmetic comments:

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1716:

> 1714:   br(Assembler::GE, valid);
> 1715:   stop("bad field offset");
> 1716:   bind(valid);

Suggestion:

  // Verify the field offset is not in the header, implicitly checks for 0
  Label L;
  subs(zr, reg, oopDesc::base_offset_in_bytes());
  br(Assembler::GE, L);
  stop("bad field offset");
  bind(L);

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 237:

> 235: 
> 236:   // Patch the bytecode using STLR so that the last STLR used in
> 237:   // ResolvedFieldEntry::fill_in is observed before the patched bytecode.

Suggestion:

  // Patch bytecode with release store to coordinate with ResolvedFieldEntry loads
  // in fast bytecode codelets. load_field_entry has a memory barrier that gains
  // the needed ordering, together with control dependency on entering the fast codelet
  // itself.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27748#pullrequestreview-3340616460
PR Review Comment: https://git.openjdk.org/jdk/pull/27748#discussion_r2432715563
PR Review Comment: https://git.openjdk.org/jdk/pull/27748#discussion_r2432740718