RFR: 8369947: Bytecode rewriting causes Java heap corruption on RISC-V

[Fei Yang]

On Fri, 17 Oct 2025 07:10:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > @shipilev @theRealAph : For the aarch64 counterpart, shouldn't the `ldarb` at [1] prevent the reordering of `STR` of PBC and `STLR` of RFE? It's a load instruction with acquire semantics.
> > 
> > 
> > Yes, I was confused about this myself. The key thing for this particular issue: the _reader_ we need to sync up with is not `patch_bytecode`, it is the thread that _executes_ the patched bytecode. In other words, the _writer_ is `patch_bytecode`, and _reader_ is executing thread.
> > So acquire barrier in `patch_bytecode` does not help this case, because it is a write path, it needs release, which aarch64 fix did. The read path needs some other synchronization for acquire-like semantics; in aarch64 we reasoned the control dependency on bytecode itself and the barrier in RFE resolution is already enough to do this.

Nice analysis! I read it several times as well and I think I know what's going on now. Thanks.

> RISCV is good on the read side, we just need this patch to fix the write:
> 
> ```
> void InterpreterMacroAssembler::load_field_entry(Register cache, Register index, int bcp_offset) {
> ...
>   // Get address of field entries array
>   ld(cache, Address(xcpool, ConstantPoolCache::field_entries_offset()));
>   addi(cache, cache, Array<ResolvedIndyEntry>::base_offset_in_bytes());
>   add(cache, cache, index);
>   // Prevents stale data from being read after the bytecode is patched to the fast bytecode
>   membar(MacroAssembler::LoadLoad);
> }
> ```

Yes, we only need the necessary barrier on the write side.

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

PR Comment: https://git.openjdk.org/jdk/pull/27850#issuecomment-3417652631