RFR: 8369506: Bytecode rewriting causes Java heap corruption on AArch64
Aleksey Shipilev
shade at openjdk.org
Thu Oct 16 11:54:05 UTC 2025
On Mon, 13 Oct 2025 08:30:17 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.
>
>> But I wouldn't bet money on it.
>
> B2.3.6, _Dependency relations, Control dependency_, gives you what you need on the reader side.
@theRealAph -- oddly, I have GH notifications about some of your recent suggestions in comments, but I do not see them in PR itself. Maybe you need to "publish" the review?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27748#issuecomment-3410497658
More information about the hotspot-compiler-dev
mailing list