RFR (S) 8240556 and RFR (S) 8248783 for G1 humongous objects

[Liang Mao]

Hi,

I just attached a test case to this bug to demonstrate the issue in our
workloads.
Both 8u and JDK15 could reproduce the same problem.
https://bugs.openjdk.java.net/browse/JDK-8248783

The high allocation rate of humongous objects will easily lead to evacuation
failures and Full GC while increasing region size can resolve the problem.
In
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
you 
guys can make some tests and let me know if it works fine for the legacy
tests as
well.

Thanks,
Liang 

> -----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).
I
> 
> made a concurrent cleaning bitmap version instead of the original STW one.
> But there are still some other problems in real world. Recently I
revisited the
> 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
and
> lead to long time STW because of to-space exhausted and even Full GC
> 2) Frequent concurrent marking will cost significant CPU resources (which
could
> be resolved by abort concurrent mark JDK-8240556)
> 3) Frequent GCs because the humongous allocation can reach IHOP very
quickly
> 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
the
> 
> young space for humongous allocation and eden allocation. Initial-mark
will be
> triggered if reserve space is invaded. My colleague helped to create a new
bug
> 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
several
> different applications, like web services, database, etc.
> 
> Our real test is done with 8u and I have created JDK15 webrevs with the
same
> logic. The code completes the test of jtreg gc/g1 and jbb2015. Could you
please
> 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/
> 
> 
> Thanks,
> Liang