Re: G1 patch of elastic Java heap

[Liang Mao]

Hi All,

Here is the user guide of G1ElasticHeap patch. Hope it will help to understand.

G1ElasticHeap
G1ElasticHeap is a GC feature to return memory of Java heap to OS to reduce the 
memory footprint of Java process. To enable this feature, you need to use G1 GC 
by options: -XX:+UseG1GC -XX:+G1ElasticHeap.

## Usage
There are 3 modes which can be enabled in G1ElasticHeap.
### 1. Periodic uncommit
Memory will be uncommitted by periodic GC. To enable periodic uncommit, use option 
-XX:+ElasticHeapPeriodicUncommit or dynamically enable the option via jinfo:

`jinfo -flag +ElasticHeapPeriodicUncommit PID`

Related options:

> ElasticHeapPeriodicYGCIntervalMillis, 15000 \
(target young GC interval 15 seconds in default) \
(eg, if Java runs with MaxNewSize=4g, young GC every 30 seconds, G1ElasticHeap will keep 15s
 GC interval and make a max 2g young generation to uncommit 2g memory)

> ElasticHeapPeriodicInitialMarkIntervalMillis, 3600000 \
(Target initial mark interval, 1 hour in default. Unused memory of old generation will be uncommitted
 after last mixed GC.)

> ElasticHeapPeriodicUncommitStartupDelay, 300 \
(Delay after startup to do memory uncommit, 300 seconds in default)

> ElasticHeapPeriodicMinYoungCommitPercent, 50 \
(Percentage of young generation to keep, default 50% of the young generation will not be uncommitted)

### 2. Generation limit
To limit the young/old generation separately. Use jcmd or MXBean to enable.
Example:

`jcmd PID ElasticHeap young_commit_percent=40 uncommit_ihop=40`

> young_commit_percent: percentage of young generation(MaxNewSize) to keep, rest of young
 generation will be uncommitted

> uncommit_ihop: Percentage to trigger G1 concurrent cycle and mixed GC (like InitiatingHeapOccupancyPercent). 
Unused memory of old generation will be uncommitted after last mixed GC.

Use MXBean:
```
MBeanServer server = ManagementFactory.getPlatformMBeanServer(); 
ElasticHeapMXBean elasticHeapMXBean = ManagementFactory.newPlatformMXBeanProxy(server,
                                                     "com.alibaba.management:type=ElasticHeap", 
                                                      ElasticHeapMXBean.class); 
elasticHeapMXBean.setYoungGenCommitPercent(40);
elasticHeapMXBean.setUncommitIHOP(40);
```

### 3. Softmx mode
Dynamically to limit the heap as a percentage of origin Xmx.

Use jcmd:

`jcmd PID ElasticHeap softmx_percent=60`

Use MXBean:

`elasticHeapMXBean.setSoftmxPercent(70);`

### Other G1ElasticHeap advanced options:
> ElasticHeapMinYoungCommitPercent, 10 \
 (Mininum percentage of young generation)

> ElasticHeapYGCIntervalMinMillis, 5000 \
 (Mininum young GC interval)

> ElasticHeapInitialMarkIntervalMinMillis, 60000 \
(Mininum initial mark interval)

> ElasticHeapEagerMixedGCIntervalMillis, 15000 \
(Guaranteed mixed GC interval, to make sure the mixed will happen in time to uncommit memory after last mixed GC)

> ElasticHeapOldGenReservePercent, 5 \
(To keep a mininum percentage of Xmx for old generation in the uncommitment after last mixed GC)

> ElasticHeapPeriodicYGCIntervalCeilingPercent, 25 \
ElasticHeapPeriodicYGCIntervalFloorPercent, 25 \
(The actual young GC interval will fluctuate between \
ElasticHeapPeriodicYGCIntervalMillis * (100 - ElasticHeapPeriodicYGCIntervalFloorPercent) / 100 and \
ElasticHeapPeriodicYGCIntervalMillis * (100 + ElasticHeapPeriodicYGCIntervalCeilingPercent) / 100 )

Thanks,
Liang





------------------------------------------------------------------
From:MAO, Liang <maoliang.ml at alibaba-inc.com>
Send Time:2019 Sep. 12 (Thu.) 17:01
To:Thomas Schatzl <thomas.schatzl at oracle.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: G1 patch of elastic Java heap

Hi Thomas,

Sorry for some late to prepare the code. Now you can see the code in following webrev:
http://cr.openjdk.java.net/~luchsh/elasticHeap/
It contains 2 patchs of hotspot and jdk against OpenJDK 8u222-ga.
Most of the core source code is in src/share/vm/gc_implementation/g1/elasticHeap.cpp

I want to explain some brief ideas of the patch:
1. G1ElasticHeap provides no addtional STW time to existent GC pauses.
  The memory commit/uncommit(mmap/munmap) will be executed in a concurrent thread because
  mmap/munmap costs significant time(more than 100ms easily on GB memory).
2. We provides 3 different evaluation modes to do the memory saving.
    a. Generation limit
      The young generation and old generation can be limited respectively by jcmd/MXBean. 
        A typical scenario is that we have a lot of applications which have large young 
      generation(default G1 is 60% as well) which is prepared for peak traffic. We don't
       need the large young generation memory all the time if not in a peak traffic.
    b. Periodic uncommit
      The young/old generation will be uncommit respectively based on young/old GC interval.
       The idea is similar to the original JEP 346 but treats young/old generation separately.
       For example, an application doesn't need to have large young generation all the time as
      described above. Periodic uncommit will save young generation memory to keep an acceptable
      young GC interval.
    c. Softmx
      It adjust the capacity of heap in runtime by jcmd/MXBean.
3.We still have some limitations that we need to make sure Xms=Xmx and save the memory in different policy. 

  I made it a single patch so it may not be friendly for reading because of a lot of code and funcionalities.
 We can discuss a single feature like young generation uncommit or concurrent uncommit first. Please let me
know if you want me to explain more details on some specific points.

Thanks,
Liang





------------------------------------------------------------------
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2019 Jun. 19 (Wed.) 18:04
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 Wed, 2019-06-19 at 17:38 +0800, 毛亮(在弦) wrote:
> 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.

  for discussion a jdk8 patch/webrev is fine I guess. I would prefer a
webrev because it can be referenced more easily though.

Thanks,
  Thomas