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

Luo, Ziyi luoziyi at amazon.com
Fri Aug 7 15:39:23 UTC 2020


Ping again. May I have a review on this?

Thanks,
Ziyi

On 7/17/20, 2:00 PM, "hotspot-gc-dev on behalf of Luo, Ziyi" <hotspot-gc-dev-retn at openjdk.java.net on behalf of luoziyi at amazon.com> wrote:

    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



More information about the hotspot-gc-dev mailing list