RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4]

[Mark Sheppard]

On Thu, 15 Feb 2024 12:13:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I've nothing to add other than to re-iterate if https://bugs.openjdk.org/browse/JDK-8316337 is made based on thread safety, then it needs to take into account the idempotent release of the underlying native memory as per the original logic. Otherwise base on your assertions the https://bugs.openjdk.org/browse/JDK-8316337 was not required
> 
> JDK-8316337 was about visibility and safe publication, it didn't introduce a way for the cleaning action to run more than once. I think we can close 8324972 and this PR.

regardless, it was logically incorrect ! All that was needed for the original change was a re-entrant lock to protect the state, there was no need to change to a record. This change does the same guaranteeing visibility and safe publication, while guarding against errant concurrent execution, making the class semantically correct, robust and thread safe. Despite your assertions you can't guarantee that multiple threads won't be running through the Dealloactor, due to some erroneous behaviour and the original logic attempted to guard against this.

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

PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1946003716