RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]

Jorn Vernee jvernee at openjdk.org
Mon Nov 4 19:13:33 UTC 2024


On Mon, 4 Nov 2024 13:17:23 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> I'm dubious about this. 
>> 
>> NVM, I see it now -`sharedSessionAlreadyAcquired` uses a `getVolatile` (which has stronger semantics), so we're in the clear.
>
> `checkValidStateRaw` synchronizes with `justClose` using handshakes so an opaque or higher load is only needed in `sharedSessionAlreadyClosed`. A `getOpaque` would probably be adequate. But I believe there is no formal restriction preventing the load from being hoisted out of the loop, so I decided to go for the strongest ordering in this exception-throwing case.

Doesn't using `setOpaque` mean that another thread may see the update to `state` before the update to `acquireCount`? i.e. the scope of a memory segment may appear closed, but the segment would still be passable to a downcall?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1828246949


More information about the core-libs-dev mailing list