8212084: Implement UseGCOverheadLimit for G1 #27936
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ter JDK-8369527 Reviewed-by: thartmann
…tLow with SerialGC Reviewed-by: tschatzl
…}ByteChannel.write Reviewed-by: alanb
Reviewed-by: psadhukhan, kizune
Reviewed-by: rhalade, mschoene, dlong, coleenp
Reviewed-by: ahgross, rriggs, rhalade, lancea, naoto
Reviewed-by: rhalade, rriggs
Reviewed-by: ahgross, rhalade, jnibedita, ascarpino, naoto
Reviewed-by: almatvee
Reviewed-by: almatvee
…ompress Co-authored-by: Jatin Bhateja <jbhateja@openjdk.org> Reviewed-by: jbhateja, xgong, galder, vlivanov
Reviewed-by: cjplummer
…ero in MemPointerParser::canonicalize_raw_summands Co-authored-by: Manuel Hässig <mhaessig@openjdk.org> Reviewed-by: mhaessig, kvn
… not loop Reviewed-by: chagedorn, kvn
Reviewed-by: almatvee
…oblemList Reviewed-by: jpai
…e class Reviewed-by: vromero
Reviewed-by: rriggs, naoto, scolebourne
Co-authored-by: Joel Sikström <jsikstro@openjdk.org> Reviewed-by: jsikstro, fandreuzzi
Reviewed-by: fandreuzzi, jsikstro
…..jndi... Reviewed-by: kevinw
Reviewed-by: mdoerr, rrich
Reviewed-by: tschatzl, fandreuzzi
…perator= with named function Reviewed-by: mhaessig, rcastanedalo
Reviewed-by: fandreuzzi, tschatzl
Reviewed-by: asemenyuk
Reviewed-by: adinn, asmehra
Reviewed-by: alanb
Reviewed-by: jvernee
Reviewed-by: dholmes, karianna
Reviewed-by: ascarpino
Reviewed-by: fyang
Reviewed-by: rrich, dbriemann
Reviewed-by: rcastanedalo, chagedorn
Reviewed-by: ayang, dholmes
Reviewed-by: chagedorn, mchevalier
|
👋 Welcome back tschatzl! A progress list of the required criteria for merging this PR into |
|
❗ This change is not yet ready to be integrated. |
Reviewed-by: dholmes, goetz
Reviewed-by: dfuchs
Reviewed-by: mgronlun
…/TestDescription.java fails with OutOfMemoryError: Metaspace Reviewed-by: dholmes, lmesnik, iklam, syan
…nt safe state Reviewed-by: fandreuzzi, egahlin
Reviewed-by: almatvee
…tion in the training run Reviewed-by: adinn, iklam
…s params Reviewed-by: weijun
… invokedynamic Reviewed-by: vlivanov
…E_LIVE Reviewed-by: lmesnik, sspitsyn, amenkov
Reviewed-by: thartmann, kvn
… fails Reviewed-by: tr, honkar, psadhukhan
Reviewed-by: almatvee
Reviewed-by: aivanov, dnguyen
Reviewed-by: iwalulya, ayang
Hi all, please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output). The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown. What is important here is how this works (derived from the Parallel GC implementation): * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a successive amount of GCs. * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME. Testing: tier1-5 without any OOMEs due to this feature, test case Thanks, Thomas
tschatzl
force-pushed
the
submit/8212084-usegcoverheadlimit
branch
from
e9d8963 to
389e5a2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
29 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi all,
please review these changes to implement the
UseGCOverheadLimitfunctionality for G1 (and make the implementation for Parallel GC have similar output).The
UseGCOverheadLimitfeature prematurely returnsnullfrom a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.What is important here is how this works (derived from the Parallel GC implementation):
Check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a successive amount of GCs. If so, keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. It is important to measure the correct cpu usage in case of the application being able to free memory on the OOME. Otherwise GC cpu usage will go down again and might result not exceeding the threshold next time, which will reset the gc counter. In that case we may ping-pong between exceeding cpu usage and not all the time.
I do not have an opinion on whether the application trying to handle OOMEs/try to recover is a good idea after having determined that overhead is too large for quite some time now; however this seems to be the only valid reason why after the first time the overhead limit is exceeded Parallel does not just always return
nullafter any subsequent GC.Note that G1 and Parallel measure CPU time differently (e.g. G1 uses the last 10 GCs, and takes concurrent work into account, while Parallel takes the last 32 GCs as "long term cpu usage". Also the memory usage calculation is different, so the overall sensitivity is different. There is nothing that can be done about this imo.
Testing: tier1-5 without any new OOMEs due to this feature (it's enabled by default in release builds like in Parallel), test case
Thanks,
Thomas
Progress
Integration blocker
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27936/head:pull/27936$ git checkout pull/27936Update a local copy of the PR:
$ git checkout pull/27936$ git pull https://git.openjdk.org/jdk.git pull/27936/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 27936View PR using the GUI difftool:
$ git pr show -t 27936Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27936.diff