G1 patch of elastic Java heap

毛亮(在弦) maoliang.ml at alibaba-inc.com
Tue Jun 18 11:25:44 UTC 2019

Dear OpenJDK developers,

Alibaba have developed an elastic heap feature for G1 GC and is willing to contribute it to OpenJDK.

As we know that in cloud environment memory is the key resource and there is already a similar implemented proposal http://openjdk.java.net/jeps/346 in OpenJDK13, our patch is an independent implementation and contains some major enhancements as following:

1. stop-the-world free
In current implementation heap shrink/expand happens in stop-the-world time (G1 remark or full GC) while uncommitting heap memory like several GB in Linux might cost hundreds of milliseconds and even up to seconds. Alibaba's online services cannot tolerate these long pauses so the new elastic heap feature do the memory uncommitment and commitment concurrently and asynchronously. The Java application can still run smoothly with G1 "low latency".

2. More effective memory return

Current heap shrink heuristic relies on a major/full GC cycle(remark or full GC) to evaluate the heap usage while our patch's policy can treat young generation and old generation respectively. The Java application can promptly save the memory of young generation(default Max 60% of heap in G1) if young GC frequency is quite low and will soon recover the young generation's memory if young GC frequency boosts.

The G1 elastic heap feature is already used in product environment in Alibaba cloud with AlibabaJDK8. We are glad to contribute it to OpenJDK upstream. Appreciate and look forward to your advises.


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

More information about the hotspot-gc-dev mailing list