[lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects [v3]

[Maurizio Cimadamore]

On Mon, 19 Jan 2026 17:57:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas
>  - Remove test as permitted
>  - Fixes, VHTMHAV now passes
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas
>  - A test
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas
>  - Attempt to fix garbage cas

The code changes look good (a test would be good tho). I left some comments to try and clarify the docs.

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2873:

> 2871:         // (see VarHandles::isAtomicFlat).
> 2872: 
> 2873:         // array 0: witness (to translate to object), 1: x (to translate to raw)

This comment is hard to read, for a number of reasons:
* it uses 0/1, but then the code uses `base`/`base + scale` (understandably so)
* translate to object/translate to raw -- yes, `x` starts off as a value object and we use the array to derive its "raw" representation, whereas witness is always a "raw" value, and stored into the array so we can get it back "as a value". But since this is finicky logic, all this should be spelled out more.
* the caller can "capture the witness" -- maybe "observe" the (last) witness would be more correct?
* "we must witness the raw value instead of the value object" -- well, even the old code was witnessing a raw value (of sort) -- the issue is how you compute such a raw value. The fix in this PR is that the raw value is accessed directly from memory (e.g. the content of `o` at offset `offset`). E.g. it feels like you are "overloading" what "raw" means -- in some cases you mean "raw == numeric, or !value", in other cases you mean "raw as in -- as accessed from memory"

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

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1734#pullrequestreview-3688009476
PR Review Comment: https://git.openjdk.org/valhalla/pull/1734#discussion_r2713216128