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

[Justin King]

On Sat, 11 Oct 2025 20:55:21 GMT, Andrew Haley <aph 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` 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.

Yes, that is what the PR relies upon. However we are still discussing internally on whether that is enough as we would rather not have a repeat N years down the line as hardware advances. I left this in draft until we figure it out and will poke you once we are more confident.

The AArch64 docs are not super clear. It does have this sentence: `A store-release guarantees that all earlier memory accesses are visible before the store-release becomes visible and that the store is visible to all parts of the system capable of storing cached data at the same time.` Which to me, a long with other terminology, seems to imply the two STLRs are enough. But I wouldn't bet money on it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27748#issuecomment-3395360285