[8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times

[Hohensee, Paul]

Lgtm, except, why you need to remove the assert from taskqueue.hpp? oops_do() doesn't seem to exist in 9, though I see an iterate() method that looks like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only when the serial collector is the only collector being compiled into Hotspot, so with your change the assert only gets compiled for that case. Is a taskqueue ever instantiated for that case?

Thanks,
Paul

On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" <jdk8u-dev-retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> wrote:

    Hi,

    Could someone please help?

    Thanks,
    Liang




    ------------------------------------------------------------------
    From:MAO, Liang <maoliang.ml at alibaba-inc.com>
    Send Time:2020 Jul. 2 (Thu.) 10:30
    To:jdk8u-dev <jdk8u-dev at openjdk.java.net>
    Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times

    Hi,

    I'm requesting the backport of 8057003 into 8u. As the description in the bug,
    it's a serious G1 issue which leads to 10X longer concurrent mark time and hang
    the Java threads for seconds. We encounter the problem in several applications.
    Since G1 is widely used in 8u, we need to fix it.

    Original bug:
     https://bugs.openjdk.java.net/browse/JDK-8057003
     http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd

    The JDK9 patch did not apply cleanly. Although it is not a small patch, I
     didn't change much except some assertions. One assertion in taskqueue.hpp
     is removed. It should be ok because it's no longer there as well since JDK9.

    8u webrev:
    http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/

    Testing:
    gc/g1, specjbb2015 with fastdebug

    Could someone please have a look and sponsor?

    Thanks,
    Liang