[crac] RFR: Backout new API to sync with Reference Handler [v3]

[Radim Vansa]

On Tue, 2 May 2023 14:03:17 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> This reverts commit 9cf1995693eead85d3807fb4c83ab38c14e27042 and makes #22 obsolete. 
>> 
>> The API introduced in 9cf1995693eead85d3807fb4c83ab38c14e27042 (waitForWaiters) and changed in #22 waits for the state when all discovered references are processed. So WaitForWaiters is used to implement predictable Reference Handling, ensuring that clean-up actions have fired for an object after it becomes unreachable.
>> 
>> I think that API was a mistake and should be reverted.
>> 
>> In general, the problem of predictable Reference Handling is independent of CRaC. So I thought about extracting that out of CRaC and found a few issues with the approach. A user needs to know what RefQueue gets References after an object becomes unreachable, to call waitForWaiters on that queue. The queue is not necessarily evident, so a deep understanding of refs and queues in an application is required to select the proper queue to wait on, and to build the right order of them to wait on. Also, it's required somehow to know the number of threads servicing a queue. And there are situations when waitForWaiters may report that all refs are processed, but some of them are not -- consider a thread that is polling a queue and gets refs to be processed but then buffers them in another queue for later, in this example waitForWaiters does not provide the guarantee that corresponding clean-up actions were performed.
>> 
>> The common and more straightforward way to have predictable clean-up is to call an explicit method like close()/release()/cleanup() that performs object-specific clean-up actions predictably.
>
> Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Bring back the test
>  - Use in-place Resource
>  - Bring back parts of the commit

I've commented out the `PhantomCleanableRef` registration for a test and in one case the test passed (other attempts failed) - I wish we could have the test failing more reliably.

Nevertheless LGTM.

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

PR Comment: https://git.openjdk.org/crac/pull/34#issuecomment-1532527018