G1 patch of elastic Java heap

[Thomas Schatzl]

Hi,

On Wed, 2019-10-09 at 16:10 +0200, Thomas Schatzl wrote:
> Hi,
> 
>    sorry for the late reply.
> 
> First, I have a more general question: lots of changes deal with 
> providing options to separately change properties generations at 
> runtime. Like if there were separate pools of young and old gen
> memory.
> 
> G1 is kind of built upon the idea that you pass a pause time goal
> and then modifies generation sizes and takes memory for the
> generations from a single memory pool as needed.
> 
> To me this indicates that automatic sizing is not working correctly,
> but there are many(?) use cases where it does not work as expected.
> This requires manual tuning in generation sizes for whatever reason.
> 
> Can you share your thoughts about this? There seems to be some bit
> of information missing to me - this is probably the reason for some
> of the dumb questions about the flags, and me being not too fond of
> them.
> 
> On 26.09.19 08:49, Liang Mao wrote:
> > 
> > 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 t
> > o 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 uncom
> > mit, use option 
> > 
> > -XX:+ElasticHeapPeriodicUncommit or dynamically enable the option v
> > ia jinfo:
> > 
> > `jinfo -flag +ElasticHeapPeriodicUncommit PID`
> 
> As far as I can tell, this setting periodically scans the heap for
> (too many?) uncommitted regions and, well, uncommits them.
> 
> Not completely sure if that is better than doing periodic gcs - as we
> do not expect to gain memory outside of a GC; in JDK12+ (I think) G1
> alwasy uncommits at the remark pause which should give most of the
> benefits.
> 
> There *may* be reason to also try to uncommit after the last mixed
> GC, but not sure if uncommit is that urgent - to some degree the
> existing JEP 346: Promptly return unused committed memory from G1 
> (https://openjdk.java.net/jeps/346) should cover some of the use
> cases. 
> I.e. after some delay (and inactivity) there will be another Remark 
> pause anyway.
> 
> The main reason why Remark has been chosen to uncommit memory is
> because we assume that the heap size at Remark (this is what adaptive
> IHOP shoots for) is the "target heap size".
> 
> 
> > Related options:
> > 
> > >  ElasticHeapPeriodicYGCIntervalMillis, 15000 \
> > 
> > (target young GC interval 15 seconds in default) \
> > (eg, if Java runs with MaxNewSize=4g, young GC every 30 seconds, G1
> > ElasticHeap will keep 15s
> >   GC interval and make a max 2g young generation to uncommit 2g mem
> > ory)
> > 
> > >  ElasticHeapPeriodicInitialMarkIntervalMillis, 3600000 \
> > 
> > (Target initial mark interval, 1 hour in default. Unused memory of 
> > old generation will be uncommitted
> >   after last mixed GC.)
> 
> This sesm to implement an unconditional concurrent cycle like with
> the CMSTriggerInterval flag for CMS.
> 
> Maybe there is a more clever alternative on triggering concurrent
> cycles like ZGC does based on the ratio between time spent by the
> mutator and the 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 g
> > eneration will not be uncommitted)
> 
> See above about separating young/old.
> 
> > 
> > ### 2. Generation limit
> > To limit the young/old generation separately. Use jcmd or MXBean to
> >  enable.
> 
> I do not understand the reason for those, see above.
> 
> [...]
> > 
> > ### 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);`
> 
> That one sounds good, and actually there is a flag SoftMaxHeapSize 
> already in the VM. Only ZGC implements it though.
> 
> I think this idea matches the specifications in 
> https://bugs.openjdk.java.net/browse/JDK-8222145 (i.e. as far as I
> can tell, the softmxpercent is a "soft"/target heap size), so I think
> this could be implemented under the SoftMaxHeapSize flag.
> 
> SoftMaxHeapSize is already manageable too, so could be modified
> already. Only the implementation is missing in G1 :)
> 
> > 
> > ### 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 i
> > n time to uncommit memory after last mixed GC)
> 
> These options seem to be mostly useful for when the allocation rate
> of the mutator is not high enough to advance the collection cycle.
> 
> Would the feature provide the requested feature? Maybe it needs
> some minor improvement, but to me it seems very burdensome to specify
> so many options...
> 

The first sentence got mangled somewhere: A guaranteed concurrent cycle
and/or the existing "Promptly return unused memory" feature would imho
implicitly provide "guaranteed" advancement in the garbage collection
cycle.

Starting a particular kind of collection seems to be almost only useful
for debugging; also while in jdk11+ triggering a mixed gc is still
possible at any time, it may not yield the expected benefit as G1 does
not maintain remembered sets all the time - i.e. most of the time there
are no old regions with remembered sets around.

Maybe the "Promptly return unused memory" feature could be adapted a
bit in cases when there is "some but still not significant" activity to
not trigger at all to cover such cases.

Thanks,
  Thomas