RFR (S): 8240556: Abort concurrent mark after effective eager reclamation of humongous objects

Liang Mao maoliang.ml at alibaba-inc.com
Thu Mar 5 07:13:38 UTC 2020


Hi All,

Now we have the bug id. I did more test to the patch. There's
a little concern in the patch that when we decide to cancle
the concurrent cycle in initial mark pause we need to clear
the next bitmap which supposes to be cleared concurrently.
In my test with -Xmx20g -Xms20g -XX:ParallelGCThreads=10,
the time spent on clearing next bitmap was consistently less
than 10ms. So I guess it could be acceptable.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8240556
Webrev:
http://cr.openjdk.java.net/~luchsh/g1hum/humongous.webrev/

Thanks,
Liang





------------------------------------------------------------------
From:MAO, Liang <maoliang.ml at alibaba-inc.com>
Send Time:2020 Mar. 3 (Tue.) 19:14
To:Thomas Schatzl <thomas.schatzl at oracle.com>; Man Cao <manc at google.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:G1: Abort concurrent at initial mark pause

Hi All,

As previous discusion, there're several ideas to improve the humongous
objects handling. We've made some experiments that canceling concurrent
 mark at initial mark pause is proved to be effective in the senario that 
frequent temporary humongous objects allocation leads to frequent concurrent
 mark and high CPU usage. The sub-test: scimark.fft.large in specjvm2008 is
also the exact case but not GC sensative so there's little difference
in score. 

The patch is small and shall we have a bug id for it?
http://cr.openjdk.java.net/~luchsh/g1hum/humongous.webrev/

Thanks,
Liang







More information about the hotspot-gc-dev mailing list