RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v6]

Kim Barrett kbarrett at openjdk.org
Sun Jun 29 20:17:40 UTC 2025


On Fri, 27 Jun 2025 20:21:07 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into direct-buffer-cleaner
>>  - Merge branch 'master' into direct-buffer-cleaner
>>  - Merge branch 'master' into direct-buffer-cleaner
>>  - Merge branch 'master' into direct-buffer-cleaner
>>  - add description of BufferCleaner class
>>  - exception handling in cleaner for backward consistency
>>  - detabify
>>  - move jdk.internal.nio.Cleaner to sun.nio
>>  - copyrights
>>  - remove java.nio use of jdk.internal.ref.Cleaner
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/e70f0479...c995d97e
>
> src/java.base/share/classes/java/nio/BufferCleaner.java line 74:
> 
>> 72:                 // reference processing by BufferCleaner, clear the referent so
>> 73:                 // reference processing is disabled for this object.
>> 74:                 clear();
> 
> Reference.clear() does not have any JMM guarantees. However, I've not found anything that might race with accessing the referent.

I'm not sure what you are concerned about here. However, the referents for
these objects aren't ever accessed by other than the GC. And we don't really
care about the potential race between clear() and GC; the atomic removal from
the cleanerList deals with any timing issues there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2173901990


More information about the nio-dev mailing list