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

[Alan Bateman]

On Mon, 19 Feb 2024 11:30:37 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> which by inference means that change https://bugs.openjdk.org/browse/JDK-8316337 was not required, also. No need for threads safety or safe publication if there is no concurrency involved

There is concurrency. The DBB is allocated in one thread, the memory backing that DBB is freed by the Cleaner thread.


> I can close it but I don't agree with the conclusion. The Deallocator should convey whether the native memory block has been freed or not, and maintained its idempotent characteristic, irrespective of concurrency or at most once semantics. The latter being wholely dependent on correct execution of Cleaner mechanism. At most once semantics should come from the implementation and the current implementation does not exhibit at most once semantics, while the original logic did provide at most once semantics for serial execution. But not for concurrent execution

Let's close it.  "At most once" is clearly specified and avoids having every cleaning action (Deallocator is just one of many in the JDK) to have to defend against being called more than once.  By "original logic" then I assume you mean the unsafe check for address == 0 and "Paranoia" comment. This pre-dates the migration to the new Cleaner and should probably have been removed a long time to avoid any confusion that it could be called more than once.

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

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