RFR: 8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC

[Luo, Ziyi]

Hi,

Please review this patch to adjust the old gen allocation rate for G1 Adaptive
IHOP to consider the humongous objects freed by young collector.

Webrev: http://cr.openjdk.java.net/~bmathiske/8245511/webrev.01/
CR: https://bugs.openjdk.java.net/browse/JDK-8245511

This revision addresses a comment from Thomas in webrev.00:
> one other improvement could be to put the old gen allocation tracking into
its own class...

This is added in JDK-8245511. This RFR refactors G1*IHOPControl to no longer
store any allocation data but read from the old gen allocation tracker
instance.

To answer the following questions from Thomas:
> Quick(!) testing on the reproducer with the suggested patch showed around
23% of young gcs were evacuation failures

The evacuation failures are "by design". The test case attached to the JBS bug
intends to create a low pressure on the survive space and then suddenly
increase the life cycle of objects in the Eden space to create a to-space
exhaustion (I checked GC log, all evacuation failures are to-space
exhaustions). This is the fastest approach I can come up with to get objects
promoted to the old gen directly to trigger enough concurrent cycles for
Adaptive IHOP to sample. Once Adaptive IHOP starts to predict, the to-space
exhaustion is no longer needed. The evacuation failures are also observed in
test run with Static IHOP. Why then are not observed without this fix? Because
GC happens every 50 ms. Even during the allocation spike, only one region is
filled up in Eden :)

> but in return the change imho needs to provide some measure of the spikyness
of the allocation between gcs. Otherwise G1 will run into to-space exhaustions
and potentially full gcs all the time with such loads.

I agree that the spikiness of the allocation between GCs should be considered
and I understand your concern here. My fix might bring the old gen allocation
rate too low that theoretically back-to-back full GC is possible. However, I
was not able to create a test case to produce it as those short-live humongous
objects are reclaimed so rapidly (my patch only accounts humongous objects
that are allocated and reclaimed in the same allocation cycle). Could you give
me some hint on how to produce the worst-case scenario?

Tests:
All hotspot tier-1 passed in fastdebug build.

Thanks,
Ziyi