8312116 GenShen: make instantaneous allocation rate triggers more timely #327
Conversation
This commit also includes a bunch of instrumentation, which is disabled by #ifdef.
…ate-trigger-quicker
|
I'm leaving this in draft mode until I complete functional and performance testing and remove the temporary instrumentation code. |
|
👋 Welcome back kdnilsen! A progress list of the required criteria for merging this PR into |
|
Experiments with various workloads show these changes to decrease the number of degenerated GCs. In some cases, the greater sensitivity of the acceleration trigger causes more frequent GCs than without it. I am experimenting with various configuration options on multiple workloads to determine an "optimal" default configuration. |
Webrevs
|
I'm filing a new ticket to explore deadlock issue related to ShenandoahControlThread::_regulator_lock. The issue was last observed on this branch. New changes that we are about to integrate will likely make it much more difficult to reproduce the issue.
Some debugging and instrumentation, which will be removed Better handling of humongous allocations, which will be upstreamed in a separate patch. A new triggering heuristic to reduce the length of idle spans as very long idle spans are causing degenerated cycles when they collide with allocation and promotion spikes.
|
@kdnilsen this pull request can not be integrated into git checkout make-instantaneous-alloc-rate-trigger-quicker
git fetch https://git.openjdk.org/shenandoah.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
openjdk
bot
added
the
merge-conflict
…alloc-rate-trigger-quicker
openjdk
bot
removed
the
merge-conflict
…rigger-quicker-gh' into make-instantaneous-alloc-rate-trigger-quicker
|
|
…alloc-rate-trigger-quicker
|
This now passes all regression tests. However, performance is not acceptable. Going to do a bit of refinement. |
If we decide to change these default values, we will need to arrange for GenShen default to be different than SingleShen default. Setting these defaults to experiment with our performance pipeline. Note that we need to sample more frequently if we are going to rely on ability to quickly respond to changes in allocation rate. When we have the ability to quickly respond to changes in allocation rate, it is more important to forget history more quickly. Otherwise, we have overly conservative triggering because we do not recognize that occassionally long cycles are not representative of typical performance.
This code does not work in its current structure. Am uploading commit so I can debug in a different environment.
Throttling desires to know allocatable memory. After old marking, we may add immediate garbage to free set, so we should recalibrate the GC trigger to make use of this increased allocation pool.
At start of this branch, the default value was 3. I experimented with larger value, but changing value on this branch is not appropriate. Perhaps further study in a separate context will motivate a change to this value.
openjdk
bot
added
the
merge-conflict
openjdk
bot
removed
the
merge-conflict
openjdk
bot
added
the
merge-conflict
|
@kdnilsen This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
@kdnilsen This pull request has been inactive for more than 16 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the |
When heuristics fail to trigger because an instantaneous "allocation spike" is not so large as to consume all available memory before GC completes, this assessment is based on an assumption that the allocation rate remains constant, and it ignores the time that will be lost due to the _interval between consecutive allocation spike measurements.
This PR watches for "acceleration" of allocation rates. When acceleration of allocation is detected in 3 consecutive allocation spike measurements, it calculates a best-fit curve (assuming constant acceleration) and predicts the memory to be consumed during the time that spans both the next sample interval and the GC effort that follows it. If the memory to be allocated according to anticipated acceleration of allocations during this time span exceeds what is available, we trigger immediately.
Progress
Integration blockers
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/shenandoah.git pull/327/head:pull/327$ git checkout pull/327Update a local copy of the PR:
$ git checkout pull/327$ git pull https://git.openjdk.org/shenandoah.git pull/327/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 327View PR using the GUI difftool:
$ git pr show -t 327Using diff file
Download this PR as a diff file:
https://git.openjdk.org/shenandoah/pull/327.diff
Webrev
Link to Webrev Comment