On Thu, 30 Jan 2025 16:54:16 GMT, Alan Bateman <al...@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
