G1 patch of elastic Java heap

[Thomas Schatzl]

Hi Liang,

On Tue, 2019-06-18 at 19:25 +0800, 毛亮(在弦) wrote:
> Dear OpenJDK developers,
> 
> Alibaba have developed an elastic heap feature for G1 GC and is
> willing to contribute it to OpenJDK.
> 

  it's always great to hear about new and interesting work done on the
OpenJDK. Thanks for contributing it back to the community. :)

> 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.

Both of these enhancements and your hints about more sound interesting
and useful, but are a bit vague. It would help if actual changes were
available somewhere to look at and discuss in detail.

Do you happen to have a changeset/webrev preferably against the jdk/jdk
branch and can put it on cr.openjdk.java.net? If that is a problem, I
can put it on my space.

Then it will be much easier to give advice about how to proceed knowing
the scope of these changes; depending on that and your preferences on
external visibility of these changes multiple options are available,
e.g.:

- split the change into a series of small enhancements maybe with a few
release notes to inform users "only"
- on the other end for maximum external visibility, do a JEP on the
whole or parts of the changes

also a mix is possible depending on how interdependent these changes
are, but I think we will probably come up with a good solution.

Thanks,
  Thomas