Change heuristics for activating compilation threads #3139
Merged
Conversation
This file contains 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
Currently the logic for activating compilation threads does not work as intended when the number of compilation threads is specified by the user. Ideally, when the user sets the number of compilation threads with `-XcompilationThreads<n>` option, the JVM should activate new threads up to 'n' based on its internal activation thresholds. However, currently the JIT will activate only (numProc-1) compilation threads (regardless of how many the user specified) and the extra compilation threads could be activated only if 'starvation' of the compilation threads is detected. This commit will change the logic as follows: 1) If the user specifies the number of compilation threads the JIT will assume that the user knows best and will activate the compilation threads based on its internal activation threasholds irrespective of the number of CPUs the JVM is allowed to run on. 2) If the user does not specify the number of compilation threads, the JVM will activate up to numProc-1 compilation threads based on its internal activation thresholds. Moreover, if more compilation threads are present and starvation of compilation is detected (this could happen in linux) then the additional existent compilation threads are activated based on a more conservative activation policy. Signed-off-by: Marius Pirvu <mpirvu@ca.ibm.com>
|
LGTM. Jenkins test sanity all jdk8 |
|
Jenkins copyright check |
|
Jenkins copyright check |
|
Jenkins line endings check |
|
The two test failures on Windows are due to infra problems. |
ymanton
approved these changes
Oct 5, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Currently the logic for activating compilation threads does not work as
intended when the number of compilation threads is specified by the user.
Ideally, when the user sets the number of compilation threads with
-XcompilationThreads<n>option, the JVM should activate new threads up to'n' based on its internal activation thresholds. However, currently the JIT
will activate only (numProc-1) compilation threads (regardless of how many
the user specified) and the extra compilation threads could be activated
only if 'starvation' of the compilation threads is detected.
This commit will change the logic as follows:
If the user specifies the number of compilation threads the JIT will
assume that the user knows best and will activate the compilation threads
based on its internal activation threasholds irrespective of the number
of CPUs the JVM is allowed to run on.
If the user does not specify the number of compilation threads, the JVM
will activate up to numProc-1 compilation threads based on its internal
activation thresholds. Moreover, if more compilation threads are present
and starvation of compilation is detected (this could happen in linux)
then the additional existent compilation threads are activated based on
a more conservative activation policy.
Signed-off-by: Marius Pirvu mpirvu@ca.ibm.com