RFR (S) 8240556 and RFR (S) 8248783 for G1 humongous objects
maoliang.ml at alibaba-inc.com
Fri Jul 10 09:47:20 UTC 2020
I just attached a test case to this bug to demonstrate the issue in our
Both 8u and JDK15 could reproduce the same problem.
The high allocation rate of humongous objects will easily lead to evacuation
failures and Full GC while increasing region size can resolve the problem.
our workloads, we have too many humongous objects even with 32m region
size. So better heuristics to trigger GCs in such scenario is important to
us. I know
it may be a big change since original heuristics exists for many years. Hope
guys can make some tests and let me know if it works fine for the legacy
> -----Original Message-----
> Subject: RFR (S) 8240556 and RFR (S) 8248783 for G1 humongous objects
> Hi Man and G1 team,
> Previously we were discussing about abort of concurrent mark(JDK-8240556).
> made a concurrent cleaning bitmap version instead of the original STW one.
> But there are still some other problems in real world. Recently I
> implementation and make more optimization and the result seems very good.
> The most severe problems in our work loads are as below:
> 1) Humongous objects allocation will invade the space of young generation
> lead to long time STW because of to-space exhausted and even Full GC
> 2) Frequent concurrent marking will cost significant CPU resources (which
> be resolved by abort concurrent mark JDK-8240556)
> 3) Frequent GCs because the humongous allocation can reach IHOP very
> even no matter w or w/o abort concurrent mark.
> Both 1) and 3) didn't have solutions yet. I made another change to share
> young space for humongous allocation and eden allocation. Initial-mark
> triggered if reserve space is invaded. My colleague helped to create a new
> ID: https://bugs.openjdk.java.net/browse/JDK-8248783
> With this change and abort concurrent mark our problematic work loads run
> very smoothly without any GC issues. I have tested the 2 changes in
> different applications, like web services, database, etc.
> Our real test is done with 8u and I have created JDK15 webrevs with the
> logic. The code completes the test of jtreg gc/g1 and jbb2015. Could you
> take a look and run some tests?
> Bug: https://bugs.openjdk.java.net/browse/JDK-8240556
> Webrev: http://cr.openjdk.java.net/~ddong/liangmao/8240556/webrev.00/
> (This may related to https://bugs.openjdk.java.net/browse/JDK-8247928)
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248783
> Webrev: http://cr.openjdk.java.net/~ddong/liangmao/8248783/webrev.00/
More information about the hotspot-gc-dev