On Mon, 25 Nov 2024 08:32:31 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
>> 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. > >> Though, for this test, CleanableList itself is not being walked. > > I think this is a matter of definition of "CleanableList itself is not being > walked". > > The Java code does not walk the list in this test, but GC does the walk the > list as part of GC cycle. This is what this test sets up: it builds the large > list of cleanable objects, makes sure the cleanable objects are reachable, so > associated cleaners stay in the list, and then forces GC to mark the entire > heap. When there is a large linked list formed by old `ClenableList` > implementation, GC times suffer, because GC cannot parallelize marking work. > This is why this benchmark improves with new implementation: GC becomes more > parallel/efficient. > >> 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. > > Yes. And "if any" in this test shows up as 2..3x improvement in GC times :) Congratulations ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1856374580
