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

Liang Mao maoliang.ml at alibaba-inc.com
Thu Jul 16 02:27:12 UTC 2020


Hi Paul,

In order to partially iterate the object array, the task queue will not
only have oop but also "array slice" which is not oop. But inserting
G1 specific code into taskqueue.hpp as below seems a little bit hacking:

+ assert((*t)->is_g1_array_slice() || (*t)->is_oop_or_null(), "Not an oop or null");

In JDK9, the oops_do() is already replaced by a common general iterate() 
which won't have that assertion. Do you think changing the assertion as
below is better?

-assert((*t)->is_oop_or_null(), "Not an oop or null");
+assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null");

Thanks,
Liang

> -----Original Message-----
> From: Hohensee, Paul [mailto:hohensee at amazon.com]
> Sent: 2020年7月16日 5:39
> To: Liang Mao <maoliang.ml at alibaba-inc.com>; jdk8u-dev <jdk8u-
> dev at openjdk.java.net>
> Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely
> long synchronization times
> 
> 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
> 
> 




More information about the jdk8u-dev mailing list