Add garbage collector aware recycler

[DanielThomas]

Testing against this patch indicates that the pooling of byte arrays when using the modern, low-pause collectors is unnecessary, because there are no pauses for evacuation failures to cause an impact to application latency.

For a 2,500 second runtime, the baseline generational ZGC cluster:

Versus generational ZGC w/ patch:

Example of overhead:

[Sunjeet]

Thanks for the PR.

One callout, this may result in a small bloat in how much extra heap a delta transition allocates- currently a delta transition can reuse a long[] from the memory pool that is already being referenced by reader threads and thats ok because those reads get invalidated later

hollow/hollow/src/main/java/com/netflix/hollow/core/read/engine/object/HollowObjectTypeReadStateShard.java

Line 361 in 1cdd463

private boolean readWasUnsafe(HollowObjectTypeDataElements data) {

Also thinking from a rollout perspective maybe good to gate this behind a feature flag.

Other than that, just noting that the status quo seems appealing from the standpoint that java GC has a smaller region to manage so maybe able to work more efficiently, making impact to read performance a little less likely. But I do see the efficiency argument with the patch that when data size shrinks hollow wont hold on to more heap than necessary. Would be good to get @dkoszewnik 's buy in.

[DanielThomas]

result in a small bloat in how much extra heap a delta transition allocates

maybe able to work more efficiently, making impact to read performance a little less likely.

Neither will be a concern with the low pause collectors. I bet G1 was the reason this optimisation was required, because evacuation failures are so expensive. The heuristics that determine the young/old balance would have had a hard time accomodating the infrequent allocation spikes caused by delta updates. It no longer matters, and in fact, promotion failures are something than Generational Shenandoah expects, IIRC it can fall back to promoting a region in place, instead of copying.

These collectors have essentially constant pause times, in the case of ZGC well below 1ms, that don't scale with heap size or allocation rates. Any impact to application latency is in things like store/load barriers, and the impact of the collector running concurrently with the application, but you've already made that trade off by your selection of GC.

[dkoszewnik]

The use of the recycler predates G1, the rationale dates back to the CMS collector. If this complexity is no longer necessary, I'm all for simplifying.

A side note -- before G1 was GA (and slightly after, IIRC), we tested with candidate versions and occasionally ran into ArrayIndexOutOfBounds exceptions where they should not have been possible -- I am certain we were running into bugs in early versions of G1. I hope these newer collectors don't have similar issues. But I don't think the use of an array segment recycler would make us any more or less likely to encounter them.