RFR: 8343704: Bad GC parallelism with processing Cleaner queues [v14]

[Aleksey Shipilev]

On Fri, 22 Nov 2024 00:17:19 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Redone the benchmark. We actually want all targets to be reachable, and only expose the Cleaner-side linked lists to the test. New performance data is updated here: https://github.com/openjdk/jdk/pull/22043#issuecomment-2470928360
>
> Would this be considered a benchmark of the GC's PhantomReference management, then - deciding that all the `PhantomCleanerRef`s are still reachable, perhaps?
> 
> To measure `CleanableList`'s list manipulation at GC-time, a `Target` needs to become unreachable, so its `PhantomCleanerRef` will come off the `ReferenceQueue` (CleanerImp.java L140). Right?

Yes, the test that makes `Cleaners` unreachable needs to be built accurately to avoid OOMe runaways. We have `CleanerChurn` benchmark (in this PR) for that. That test churns cleaners, so allocation path is invoked to insert new cleaners and GC is implicitly invoked to clean them up. See if that one makes sense to you?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1853373690