On Sat, 23 Nov 2024 01:38:00 GMT, Brent Christian <bchri...@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
