RFR: 8371923: Update LockFreeStack for Atomic<T> [v2]

[Kim Barrett]

On Tue, 18 Nov 2025 10:48:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the `LockFreeStack` utility to allow clients to
>> use `Atomic<T>` as the type of the "next" member used in the linked-list
>> representation of the stack. It also continues to allow clients to use the old
>> (pre-`Atomic<T>`) form where the "next" member is volatile. This allows
>> clients to be updated incrementally after this change, rather than requiring
>> all clients to be updated in conjunction with the update of this class. Once
>> all clients have been updated, support for the old form can be removed.
>> 
>> The associated gtests have been updated to use `Atomic<T>`, with testing of
>> the old form is no longer being done. The non-updated uses provide some
>> testing, and that's all expected to go away soon. So parameterizing the gtests
>> for both forms seems like a bunch of work that will just be deleted soon, with
>> very little benefit.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into lock-free-stack-allows-new-atomic
>  - rename next_access to next_accessor
>  - LockFreeStack supports Atomic<T>

> Overall looks good. Thanks.
> 
> > This allows clients to be updated incrementally after this change, rather than requiring all clients to be updated in conjunction with the update of this class.
> 
> @kimbarrett I only see four clients of this code:
> [...]
> is the required update so disruptive that you can't just do it here?

There are fewer clients than I remembered. I think there were at least one or
two more in the recently replaced G1 post-barrier code.

But at least some of the current clients have a number of other atomic uses.
I'd rather not partially update them to just deal with their use of this
class. And I'd rather not completely do all of them in one change set.

The code to do the conditionalization in LockFreeStack is pretty small,
simple, and localized. (There was an earlier version that was also supporting
NonblockingQueue, but that class was recently removed because it is no longer
used (again by the replacement of the G1 post-barrier code), rather than
updating its atomic usage. That version of the conditionalization involved
somewhat more code.)

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

PR Comment: https://git.openjdk.org/jdk/pull/28329#issuecomment-3551169359