OpenJDK G1 Patch

Mon May 21 08:29:32 UTC 2018

Hi Kirk,

please remember that some years back we had to patch a similar parameter to the CMS (CMSTriggerInterval) which helps us to regularly clean/sweep the complete heap. We have an application framework where we massively use weak references as a sort of smart pointers where we need the garbage collector to at least regularly tell us that objects are not referenced from the application layer anymore. The application framework objects are memory and CPU and network bound as an existence of an object in the heap means receiving thousands of updates with necessary decoding and value updates. Unfortunately all CMS/G1/… collectors see an allocated object as a memory resource ignoring the fact that there might be other machine resources coupled with the object being alive. 

We are still using the CMS as all G1 tests indicate 2-3x performance degradation of the ParNew like phase. We were not looking yet for the CMSTriggerInterval parameter replacement in the G1, but something like the GCFrequency parameter will be required for us as well to keep our application framework working. Obviously the regularly trigged all regions evacuation should be as much concurrent as it can be and not just a simple full collection.

We hope there will be another alternative when CMS is killed for G1 to live.

Regards,
Michal Frajt 

Od: "hotspot-gc-dev" hotspot-gc-dev-bounces at openjdk.java.net
Komu: "Rodrigo Bruno" rbruno at gsd.inesc-id.pt
Kopie: "hotspot-gc-dev at openjdk.java.net openjdk.java.net" hotspot-gc-dev at openjdk.java.net,"Ruslan Synytsky" rs at jelastic.com
Datum: Mon, 21 May 2018 14:45:05 +0900
Předmet: Re: OpenJDK G1 Patch

Hi Rodrigo,
Interesting idea. IMHO, this solution is too simplistic as it focuses on the needs of providers at the detriment of the goals of the consumers.Full collections in normal G1 work loads tend to be very pause expensive and one of the goals when tuning the garbage collector is to make sure you never see all Full collection. I would suggest that a better, but more complex system would be work with some how making adjustments to how regions are selected for evacuation. Some how favoring those regions whose memory maybe returned to the OS.
That said, it is my current opinion that ZGC or Shenadoha will replace G1 given that they promise better pause time characteristics. Once these collector do become more popular you will end up with the same situation. Again, triggering a full collection to solve your problem may not be in the best interest of applications owners.
Kind regards,Kirk Pepperdine
On May 20, 2018, at 3:01 AM, Rodrigo Bruno <rbruno at gsd.inesc-id.pt> wrote:
Dear OpenJDK community,
Jelastic and INESC-ID have developed a patch for OpenJDK that improves elasticity of JVM with variable loads. The detailed description of the patch can be found below. We would like share this patch with the community and push it to the mainstream. We believe this work will help Java community to make JVM even better and improve the memory resources usage (save money) in the modern cloud environments. A more complete patch description can be found in the paper that will be presented in ISMM 2018.

Elastic JVM Patch Description
Elasticity is the key feature of the cloud computing. It enables to scale resources according to application workloads timely. Now we live in the container era. Containers can be scaled vertically on the fly without downtime. This provides much better elasticity and density compared to VMs. However, JVM-based applications are not fully container-ready. The first issue is that HotSpot JVM doesn’t release unused committed Heap memory automatically, and, therefore, JVM can’t scale down without an explicit call of the full GC. Secondly, it is not possible to increase the size of JVM Heap in runtime. If your production application has an unpredictable traffic spike, the only one way to increase the Heap size is to restart the JVM with a new Xmx parameter. 
To solve these 2 major issues and make JVM more container friendly, we have implemented the following improvements: i) timely reduce the amount of unused committed memory; and ii) dynamically limit how large the used and committed memory can grow. The patch is implemented for the Garbage First collector.

Timely Reducing Unused Committed Memory
To accomplish this goal, the HotSpot JVM was modified to periodically trigger a full collection. Two full collections should not be separated by more than GCFrequency seconds, a dynamically user-defined variable. The GCFrequency value is ignored and therefore, i.e., no full collection is triggered, if:
GCFrequency is zero or below;the average load on the host system is above MaxLoadGC. The MaxLoadGC is a dynamically user-defined variable. This check is ignored if MaxLoadGC is zero or below;the committed memory  is above MinCommitted bytes. MinCommitted is a dynamically user-defined variable. This check is ignored if MinCommitted is zero or below;the difference between the current heap capacity and the current heap usage is below MaxOverCommitted bytes. The MaxOverCommitted is a dynamically user-defined variable. This check is ignored if MaxOverCommitted is zero or below;

The previously mentioned concepts are illustrated in the figure below:

The figure above depicts an application execution example where all the aforementioned variables come into play. The default value for all introduced variables (GCFrequency, MaxLoadGC, MaxOverCommitted, and, MinCommitted) is zero. In other words, by default, there are no periodic GCs.

With this these modifications, it is possible to periodically eliminate unused committed memory in HotSpot. This is very important for applications that do not trigger collections very frequently and that might hold high amounts of unused committed memory. One example are web servers, whose caches can timeout after some minutes and whose memory might be underutilized (after the caches timeout) at night when the amount of requests is very low.
-Xmx Dynamic Limit Update 
To dynamically limit how large the committed memory (i.e. the heap size) can grow, a new dynamically user-defined variable was introduced: CurrentMaxHeapSize. This variable (defined in bytes) limits how large the heap can be expanded. It can be set at launch time and changed at runtime. Regardless of when it is defined, it must always have a value equal or below to MaxHeapSize (Xmx - the launch time option that limits how large the heap can grow). Unlike MaxHeapSize, CurrentMaxHeapSize, can be dynamically changed at runtime.
For example dynamically set 1GB as the new Xmx limit
jinfo -flag CurrentMaxHeapSize=1g <java_pid>
Setting CurrentMaxHeapSize at runtime will trigger a full collection if the desired value is below the current heap size. After finishing the full collection, a second test is done to verify if the desired value is still above the heap size (note that a full collection will try to shrink the heap as much as possible). If the value is still below the current heap size, then an error is reported to the user. Otherwise, the operation is successful. 
The limit imposed by the CurrentMaxHeapSize can be disabled if the variable is unset at launch time or if it is set to zero or below at runtime.
This feature is important to cope with changes in workload demands and to avoid having to restart JVMs to cope with workload changes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180521/6e1bc410/attachment.htm>