backport JEP 344-Abortable Mixed Collections for G1 to jdk11u

[臧琳]

Dear Thomas and Charlie,
     Thanks for your suggestions.
     Let me describe more about my experiment.  I am trying JDK11 on some sort of server node with huge heap at ~400GB. And it needs to keep the responsiveness so that long pause time of GC is not acceptable.
    And for some reason, if the server node paused for a long time (say 60s), the whole process will be killed and hence cause disaster.
    With JDK11 using G1， after some measurement I believe that keep MaxGCPauseMills at 200ms is reasonable and works well when there is no MixedGC - And also want to mention that the server node is super busy at allocation so there are usually 2~3 YGCs per minute.
    The problems comes with Mixed GC, I observed mainly two issues about it:
          a. There is super long pause time for MixedGC.  Some times I found the whole process is killed because the MixedGC paused over 60s.
          b. There is back-to-back long MixedGCs, for examples, there can be 2~3 mixedGC within one minutes, and every one of them tooks ~30s. so the process get killed.
   For issue a, I think it seems that the collection set may be too large to be collected in low pause times. So I have tried to enlarge XX:G1MixedGCCountTarget to reduce the CSet for every MixedGC. But it seems this option could introduce more MixedGCs overall, which affected more or less of latency when normal MixedGCs happened. (Usually there is a batch of mixedGCs after concurrent marking, and seems the count of mixedGCs in a batch grows by enlarging  XX:G1MixedGCCountTarget ), and this may cause issue b more severe.
   I also tried the option of -XX:G1HeapWastePercent, and it could more or less help reduce the MixedGC pause, but it shows if I enlarge it too much , more MixedGCs are going to happened.

   I come to consider that those options are good but they takes effect to all mixedGC’s, even for the cases that MixedGC pause time are acceptable.I tried to find a way to control the Cset by pause times, and I found the JEP344, after trying it in my case the long pause mixedGC is reduced by only introducing more low pause mixedGCs in that specific batch.

   PS. for the issue b mentioned, I think JEP344 may not help a lot. My data shown it comes from the updateRS&scanRS time, the tuning guide mentioned that so I will try it.
   And thanks for guiding me, I also cc this thread to  jdk-updates-dev.


BRs,
Lin


在 2019年3月29日，上午3:31，Thomas Schatzl <thomas.schatzl at oracle.com<mailto:thomas.schatzl at oracle.com>> 写道：

Hi Lin,

On Wed, 2019-03-27 at 10:51 +0000, 臧琳 wrote:
Dear All,
    I have tried the JEP344 for a while and find it could help us to
avoid the long Mixed GCs when the heap is large.

It is great to hear that it helps you in your case.

I assume you tried some tuning with the options presented in the
documentation at
https://docs.oracle.com/en/java/javase/12/gctuning/garbage-first-garbage-collector-tuning.html#GUID-D2B6ADCE-6766-4FF8-AA9D-B7F4F3D0F469
?

Note that in some cases this still might not result in as nice behavior
as with abortable mixed gc.

    So I am planning to port it back to jdk11u as G1 is the default
GC, do you think it is reasonable?

 I believe it is okay if it is useful, but it is best to ask the
maintainers of jdk11u directly in on the jdk-updates-dev mailing list.
As this would be a bit bigger change/backport, so there might be some
further concerns by the jdk11u maintainers.

Code review seems to have to occur on the jdk-updates-dev mailing list
(https://openjdk.java.net/projects/jdk-updates/codereview.html) - maybe
cc hotspot-gc-dev though.

Thanks,
 Thomas



BRs,
臧琳 Lin Zang
京东零售-数据中台-数据基础平台部-平台架构部-高性能集群研发部
---------------------------------------------------------------
手机／+86 15801317152
邮箱／zanglin5 at jd.com<mailto:zanglin5 at jd.com>
地址／北京市亦庄经济技术开发区经海七路科创11街8号院
---------------------------------------------------------------
[cid:image001.png at 01D4E4CB.41D6B0B0]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190329/5c07f5ae/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 12238 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190329/5c07f5ae/image001.png>