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

Aleksey Shipilev shade at openjdk.org
Wed Nov 27 17:25:43 UTC 2024


On Sat, 23 Nov 2024 01:38:00 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> 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.

So, @bchristi-git -- are you happy with current version, or?

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

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


More information about the core-libs-dev mailing list