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

[Anton Kozlov]

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

Turns out we cannot avoid synchronizing Cleaners with the checkpoint, otherwise, some native resources may remain open, if they are released as a result of running a Cleaner. This happens with JarFileFactory, which maintains a cache of URLJarFiles. To avoid their tracking, a lightweight GC-based tracking is implemented [1], that only requires that unused entries are reachable only from the cache. But it relies on Cleaner to run all the actions.

The latest version declares PhantomCleanableRef's to be Resources, which triggers clean() on the checkpoint, rather than waiting for the ref to be processed by a reference processor thread.

This preserves Cleaner behavior w.r.t. checkpoint, so the test is also retained.

[1] https://github.com/openjdk/crac/blob/95394e84683f1a816c0283f8c834072324516fba/src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java#L255

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

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