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