Re: G1 patch of elastic Java heap

[毛亮(在弦)]

Hi Thomas,

Thank you for your quick reply. 
As we implemented this feature in AlibabaJDK8, do you think if it is feasible to just provide a CR based on JDK8? 
So that you guys can have a look and then we can continue discussing on the possible JEP and implementations in upstream.

Otherwise we need spend time on preparing patches based on tip for further discussion...

BTW, I'm surely covered by the Alibaba OCA entry.

Thanks,
Liang

------------------------------------------------------------------
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2019 Jun. 19 (Wed.) 15:37
To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: G1 patch of elastic Java heap

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

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