On Fri, 22 Nov 2024 06:59:45 GMT, Aleksey Shipilev <sh...@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
