RFR: 8344665: Refactor PartialArrayState allocation for reuse [v4]

[Kim Barrett]

On Wed, 4 Dec 2024 13:40:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> This is part of the usual reference counting dance. Except, where did the
>> acquire disappear to? There should be an acquire on the refcount == 0 branch!
>> Looks like I accidentally deleted it. Sigh. Not too surprisingly, lots of
>> tests were run without noticing that.
>
> Make sense. My next question is that, if `PartialArrayState` is ever crossed thread boundaries, it is through job stealing via task queues. Can we depend on barriers of task queue to ensure the memory safety? because we don't need any additional barriers for objects popped/stole from task queues in other places.

Yes, it's needed.  The purpose of this release/acquire pair is to ensure there
is a happens-before chain between the use of a State and it's cleanup/reuse.
Transfers through the taskqueue don't help with that.

In other places, we have operations on one side of the taskqueue that need to
be ordered wrto operations on the other side of the taskqueue.  We don't have
that here.

Consider two threads which have both obtained access to a State.  (At least
one of them must have obtained it via stealing from another thread.)  Assume
these are the last two references to the State (it's refcount == 2), and no
further tasks for it will be needed.  These two threads will use the State
(getting source/destination, claiming a chunk), and then release the State,
decrementing its refcount.  So one of them will decrement to 0.  We need to
ensure the cleanup that follows that can't corrupt the use by the accesses
made by the other thread, by ensuring those accesses happen-before the
cleanup.  There is no intervening taskqueue manipulation in this scenario.
The operations we need to order are all on the same side of the taskqueue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22287#discussion_r1869759960