On Mon, 20 Jan 2025 17:37:19 GMT, Alan Bateman <al...@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
