RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v3]

[Aleksey Shipilev]

On Mon, 20 Jan 2025 17:37:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Note that the long standing recommendation has always been to cache/reuse direct buffers rather than discard like the reproducer does

The reproducer is likely overly simplistic. The performance problem we are solving is non-parallelism in GC when processing backing Cleaner lists.

Actually, this reminds me that I need to add direct churn/GC tests like we did for [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704) to verify the DBB-like scenarios also improve. I pushed some benchmarks, going to see how they perform now.

> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 86:
> 
>> 84:                 Bits.unreserveMemory(size, capacity);
>> 85:             } catch (Throwable x) {
>> 86:                 // Old jdk.internal.ref.Cleaner behavior: when it fails, VM exits.
> 
> I'd prefer not reference a class that no longer exists, instead just say that it preserves long standing behavior exit the VM. In the case of DBB, I can't think what exceptions/errors are possible here.

Amended the comment.

> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 100:
> 
>> 98:         private static final Cleaner CLEANER = Cleaner.create();
>> 99: 
>> 100:         public static Cleanable register(Object buffer, Runnable action) {
> 
> Why is this public?

It is a public method in a private nested class. This method is used from the enclosing class, so private would be weird? I can drop public, though, let it be package-private. Done in new commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2603094715
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1922775259
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1922775141