Heap size startup hints #4168

amicic · 2019-01-02T22:12:12Z

Initial contribution of feature where on PHASE_NOT_STARTUP phase change
GC will store current heap sizes (optionally, averaged with already
existing stored values) into Shared Cache. During early startup GC will
use these hints to expand heap beyond default or even explicitly
specified sizes.

This should help large workloads to avoid early GCs while heap is
aggressively expanding, which in turn may help with startup times.

In this contribution, Standard group of GC policies are covered, with
Balanced GC following at a later point.

For Flat heap configurations (optthruput/optavgpause) only the total
heap size is maintained/expanded, while for generational configuration,
Tenure and Nursery are separately maintained/expanded.

The feature is disabled by default, but can be enabled by specifying
value [1-100] to -XXgc:heapSizeStatupHintWeightNewValue= command line
option. Reasonable value is 80, which should typically take about 5
restarts for hints to converge to stable values. Value 0 (currently
defaults) means that new values are never accounted for, which means
that values are always 0, which effectively means that feature is
disabled. Value 100 would mean that only use the hints from the most
recent run, hence no historical averaging.

Another tuning options is -XXgc:heapSizeStatupHintConservativeFactor=
Default value is 70. It means that conservatively only 70% of the hint
values are taken.

An example of verbose GC stanzas reporting the expand just after
initialized stanza is complete, before even first GC:

.....
</initialized>

<heap-resize id="2" type="expand" space="nursery" amount="1461583872"
count="1" timems="1.738" reason="hint from previous runs"
timestamp="2019-01-03T12:59:54.909" />
<heap-resize id="3" type="expand" space="tenure" amount="200212480"
count="1" timems="0.930" reason="hint from previous runs"
timestamp="2019-01-03T12:59:54.910" />

Signed-off-by: Aleksandar Micic amicic@ca.ibm.com

amicic · 2019-01-02T22:12:37Z

Dependent on eclipse-omr/omr#3415

dmitripivkine · 2019-01-02T22:24:21Z

runtime/gc_modron_startup/mminit.cpp

+				hintDefault = (UDATA)(extensions->heapSizeStatupHintWeightNewValue * hintDefault + (1.0 - extensions->heapSizeStatupHintWeightNewValue) * hintDefaultOld);
+				hintTenure = (UDATA)(extensions->heapSizeStatupHintWeightNewValue * hintTenure + (1.0 - extensions->heapSizeStatupHintWeightNewValue) * hintTenureOld);
+
+				vm->sharedClassConfig->storeGCHints(currentThread, hintDefault, hintTenure, true);


as we discussed we should double check are we allowed to update shared cache every JVM run

The hints in the shared cache can be updated, although it does lock down the cache while doing so. Fewer updates are better. The hints are updated in place, there is no shared cache expansion involved.

There is only a single update per VM run (on PHASE_NOT_STARTUP transition).

It basically serializes JVM startup. i.e. say 100 JVMs are started at the same time, all of them will wait to update the shared cache, one at a time.

dmitripivkine

I believe this is good start point implementation. We should double check:

Are we allowed to modify shared cache every JVM run?
Is it cheap to call findGCHints() twice (or values should be stored in GC Extensions)?
Can asynchronous call of gcExpandHeapOnStartup() potentially interfere with any concurrent GC activity?

amicic · 2019-01-03T16:11:45Z

@dmitripivkine, all valid concerns.

Best to my current understanding, shared cache will indeed grow an every update. It's not a large update, in order of 100 bytes, but still, it would be bad to allow unbounded updates for the final solution.
Based on my limited testing, I'd like to have the updating capability, since I can see that hint sizes need a few update before they really converge. So, we can cap the number of updates to some number (10 or so) or we can stop updating when we sense that values did converge (for example, the updated value is within 10-20% of previous value). We'll know better if the updates are really useful at all and if yes till what point after some more feedback from other people/workloads. Since, the feature is disabled by default, I dont see the unbounded updates as immediate concern for this initial implementation.
Not sure about this, but i'll try to find out
Indeed, it's quite possible we'll need to ensure that overlap does not happen. Changing boundaries of Tenure/Nursery in a middle of Concurrent Mark/Scavenger for various reasons is dangerous. We should probably add same expand functionality at a beginning of any GC, so that which ever one comes first (async one at startup or first GC) does it.

dmitripivkine · 2019-01-07T20:21:26Z

I spoke with @DanHeidinga and @pshipton about my questions. Just to summarize:

Are we allowed to modify shared cache every JVM run?

Yes. Adding a limit of number of times to be updated seems is a good idea. Value is updated at place, no structure grows occur. However writing to shared classes cache would require monitor enter (possible slow down)

Is it cheap to call findGCHints() twice (or values should be stored in GC Extensions)?

Yes. These values are cached.

charliegracie · 2019-01-08T15:57:44Z

runtime/gc_modron_startup/mminit.cpp

+
+	if (NULL != sharedClassConfig) {
+		if (extensions->isStandardGC()) {
+			uintptr_t hintDefault, hintTenure;


Can you add default values?

charliegracie

Approved based on my one suggestion being applied

Initial contribution of feature where on PHASE_NOT_STARTUP phase change GC will store current heap sizes (optionally, averaged with already existing stored values) into Shared Cache. During early startup GC will use these hints to expand heap beyond default or even explicitly specified sizes. This should help large workloads to avoid early GCs while heap is aggressively expanding, which in turn may help with startup times. In this contribution, Standard group of GC policies are covered, with Balanced GC following at a later point. For Flat heap configurations (optthruput/optavgpause) only the total heap size is maintained/expanded, while for generational configuration, Tenure and Nursery are separately maintained/expanded. The feature is disabled by default, but can be enabled by specifying value [1-100] to -XXgc:heapSizeStatupHintWeightNewValue= command line option. Reasonable value is 80, which should typically take about 5 restarts for hints to converge to stable values. Value 0 (currently defaults) means that new values are never accounted for, which means that values are always 0, which effectively means that feature is disabled. Value 100 would mean that only use the hints from the most recent run, hence no historical averaging. Another tuning options is -XXgc:heapSizeStatupHintConservativeFactor= Default value is 70. It means that conservatively only 70% of the hint values are taken. An example of verbose GC stanzas reporting the expand just after initialized stanza is complete, before even first GC: ``` ..... </initialized> <heap-resize id="2" type="expand" space="nursery" amount="1461583872" count="1" timems="1.738" reason="hint from previous runs" timestamp="2019-01-03T12:59:54.909" /> <heap-resize id="3" type="expand" space="tenure" amount="200212480" count="1" timems="0.930" reason="hint from previous runs" timestamp="2019-01-03T12:59:54.910" /> ``` Signed-off-by: Aleksandar Micic <amicic@ca.ibm.com>

dmitripivkine · 2019-01-08T17:32:57Z

Jenkins test sanity xLinux jdk11

Caused by eclipse-openj9#4168 20:51:30 mmparseXXgc.cpp(950) : error C2220: warning treated as error - no 'object' file generated 20:51:30 mmparseXXgc.cpp(950) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data 20:51:30 mmparseXXgc.cpp(964) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data Signed-off-by: Aleksandar Micic <amicic@ca.ibm.com>

Related to eclipse-openj9#4168 and eclipse-openj9#3743 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>

pshipton · 2019-01-09T04:46:29Z

btw the options contain a typo "Statup"

pshipton · 2019-01-11T13:44:57Z

@amicic do you want me to open a new issue for the typo in the option names?
Also the new options have not been documented in the user guide. Is this the desired behavior while we experiment with the new options?

amicic · 2019-01-11T14:22:22Z

@pshipton Thanks for noticing the typo. It is about to be fixed (#4240). I don't think we really need an issue for that.

We will probably introduce a anew public option (@charliegracie mentioned something like -XX:+/-UseGCStartupHints, you are laos welcome to suggest something else - should we mention sharedcache in the name?) that we'd document. The two existing ones, I would not document (and I'm not even completely sure they will stay around after we do some more experimentation).

pshipton · 2019-01-11T15:37:43Z

I'm thinking UseGCStartupCacheHints or a variation of this that mentions the shared cache would be better.

dmitripivkine added the comp:gc label Jan 2, 2019

amicic requested a review from dmitripivkine January 2, 2019 22:14

amicic force-pushed the heapsizehints branch from ac1da8c to 736495f Compare January 2, 2019 22:17

dmitripivkine reviewed Jan 2, 2019

View reviewed changes

dmitripivkine requested a review from charliegracie January 2, 2019 23:13

amicic force-pushed the heapsizehints branch from 736495f to a9cd7b8 Compare January 3, 2019 16:34

dmitripivkine approved these changes Jan 3, 2019

View reviewed changes

dmitripivkine changed the title ~~Heap size startup hints~~ WIP:Heap size startup hints Jan 3, 2019

amicic force-pushed the heapsizehints branch 2 times, most recently from 59752e4 to 43d5578 Compare January 3, 2019 17:23

DanHeidinga mentioned this pull request Jan 4, 2019

Shared cache hints for GC heap size #3743

Closed

charliegracie reviewed Jan 8, 2019

View reviewed changes

charliegracie approved these changes Jan 8, 2019

View reviewed changes

amicic force-pushed the heapsizehints branch from 43d5578 to f626d6c Compare January 8, 2019 16:44

dmitripivkine changed the title ~~WIP:Heap size startup hints~~ Heap size startup hints Jan 8, 2019

dmitripivkine merged commit 8d181eb into eclipse-openj9:master Jan 8, 2019

amicic mentioned this pull request Jan 9, 2019

Fix compile error #4213

Merged

pshipton mentioned this pull request Jan 9, 2019

WIP Optimize j9shr_storeGCHints() to avoid storing unchanged data #4214

Closed

pshipton added a commit to pshipton/openj9 that referenced this pull request Jan 9, 2019

Optimize j9shr_storeGCHints() to avoid storing unchanged data

f4541e0

Related to eclipse-openj9#4168 and eclipse-openj9#3743 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Heap size startup hints #4168

Heap size startup hints #4168

amicic commented Jan 2, 2019 •

edited

Loading

amicic commented Jan 2, 2019

dmitripivkine Jan 2, 2019

pshipton Jan 7, 2019 •

edited

Loading

amicic Jan 8, 2019

pshipton Jan 8, 2019

dmitripivkine left a comment

amicic commented Jan 3, 2019 •

edited

Loading

dmitripivkine commented Jan 7, 2019 •

edited

Loading

charliegracie Jan 8, 2019

amicic Jan 8, 2019

charliegracie left a comment

dmitripivkine commented Jan 8, 2019

pshipton commented Jan 9, 2019

pshipton commented Jan 11, 2019

amicic commented Jan 11, 2019

pshipton commented Jan 11, 2019

Heap size startup hints #4168

Heap size startup hints #4168

Conversation

amicic commented Jan 2, 2019 • edited Loading

amicic commented Jan 2, 2019

dmitripivkine Jan 2, 2019

Choose a reason for hiding this comment

pshipton Jan 7, 2019 • edited Loading

Choose a reason for hiding this comment

amicic Jan 8, 2019

Choose a reason for hiding this comment

pshipton Jan 8, 2019

Choose a reason for hiding this comment

dmitripivkine left a comment

Choose a reason for hiding this comment

amicic commented Jan 3, 2019 • edited Loading

dmitripivkine commented Jan 7, 2019 • edited Loading

charliegracie Jan 8, 2019

Choose a reason for hiding this comment

amicic Jan 8, 2019

Choose a reason for hiding this comment

charliegracie left a comment

Choose a reason for hiding this comment

dmitripivkine commented Jan 8, 2019

pshipton commented Jan 9, 2019

pshipton commented Jan 11, 2019

amicic commented Jan 11, 2019

pshipton commented Jan 11, 2019

amicic commented Jan 2, 2019 •

edited

Loading

pshipton Jan 7, 2019 •

edited

Loading

amicic commented Jan 3, 2019 •

edited

Loading

dmitripivkine commented Jan 7, 2019 •

edited

Loading