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

[Brent Christian]

On Fri, 22 Nov 2024 06:59:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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, this is a test that says "User allocated lots of Cleaner-carrying objects, and all of them are alive. See if GC chokes in this conditions." This is similar to the cases we are seeing in our prod conditions: these objects do not churn much, and the problem is in GC time hiccups to walk the large linked lists.
> 
> 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?

How about this:

> ...the problem is in GC time hiccups to walk the large linked lists.

Though, for this test, `CleanableList` itself is not being walked.

Rather, `CleanableList` itself is a factor in as much as it exists on the heap, populated with `PhantomCleanableRef`s.

So this test measures what effect, if any, the conversion from the old linked list to new CleanableList has on GC, when referents are _not_ becoming unreachable.

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

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