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

[Aleksey Shipilev]

On Thu, 30 Jan 2025 16:54:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @kimbarrett Do you have a change coming to allow waitForPendingReferences be used by WB? I assume this will at least add a comment to the method (or whatever it changes to) to make it clear that it's for testing.
>
>> @AlanBateman I've not done any work on JDK-8305186. There has also been discussion about making that function non-private or even public (though with concerns about specification difficulty) for use in places like this.
> 
> Exposing this in this API might be scary, I think would need a lot of thinking to be confident it doesn't create an attractive nuisance. Keeping it for WB testing is okay of course.

The asynchronicity of buffer cleanup would IMO always be a headache, so we would need some sort of feedback loop. Cleaner canary is not a perfect vehicle for this, since it does not tell us directly that any buffer cleanup happened, like it used to be with reference handling thread invoking `jdk.internal.ref.Cleaner` directly. We could reinstate the similarly-shaped hack by tracking if buffer-attached cleaners have fired.

That said, I have been in the room when this hack was introduced, we recognized it was not perfect, and I remember we were happy this kind of feedback still worked in practice, seeing no failures on `DirectBufferAllocTest` stress tests. So when introducing the canaries, I planned to arrive to the same happy point: stress`DirectBufferAllocTest` works in all practical configurations.

There could probably be cases where we would throw OOME, when we could have waited a bit more or do a bit more cleanups. But then again, this would not be a correctness issue, but rather a performance pothole, which is, again, does not show up on stress tests, so the probability of it seems fairly low.

So while we are discussing this, I think we should really keep an eye on practical cost-benefit balance here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1935969193