New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unbounded GC Thread Pool Expansion for CRIU Restore #16666
Merged
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
RSalman
force-pushed
the
criu-v3
branch
2 times, most recently
from
February 3, 2023 16:54
2cf4a9e
to
717f5af
Compare
@amicic @dmitripivkine @tajila please review |
amicic
reviewed
Feb 3, 2023
amicic
reviewed
Feb 3, 2023
RSalman
force-pushed
the
criu-v3
branch
4 times, most recently
from
February 6, 2023 18:59
1773c91
to
58f4174
Compare
Initial set of changes to expand the GC thread pool beyond the dispatcher initialization done at VM startup. These changes are required by the consumed OMR GC dispatcher/configuration APIs called for restore. - Converted reference obj list iteration count from `gcThreadCount` to `regionExtension->_maxListIndex`, this is more correct. This is the only instance in the code where iteration implies the listCount from GC thread count. This inference was not an issue as the lists are inited based on the GC thread count, however now that the thread count may change, it is incorrect to assume the list count from the thread count. - Release restore thread's VM access for the duration of `reinitializeGCThreadCountForRestore` Signed-off-by: Salman Rana <salman.rana@ibm.com>
Latest changes:
|
amicic
reviewed
Feb 7, 2023
amicic
approved these changes
Feb 9, 2023
Jenkins test sanity win jdk11 |
Jenkins compile aix jdk8 |
Jenkins test sanity xlinuxcriu jdk17 |
Jenkins compile aix jdk8 |
Restarted a failed aix compile, although this seemed like an infra problem. Merging... |
RSalman
added a commit
to RSalman/openj9
that referenced
this pull request
Feb 10, 2023
Move init of `_maximumDefaultNumberOfGCThreads` filed to ctor init list. Config Delegate's field `_maximumDefaultNumberOfGCThreads` const decleration was removed in. eclipse-openj9#16666. This resulted in DDR compile errors: ``` [exec] "gc_glue_java/ConfigurationDelegate.hpp", line 67: error: data member [exec] initializer is not allowed [exec] uintptr_t _maximumDefaultNumberOfGCThreads = 64; ``` Signed-off-by: Salman Rana <salman.rana@ibm.com>
keithc-ca
added a commit
to keithc-ca/openj9
that referenced
this pull request
Mar 23, 2023
Required to enable CRIU support since eclipse-openj9#16666. Signed-off-by: Keith W. Campbell <keithc@ca.ibm.com>
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.
Initial set of changes to expand the GC thread pool beyond the dispatcher initialization done at VM startup. These changes are required by the consumed OMR GC dispatcher/configuration APIs called for restore.
gcThreadCount
toregionExtension->_maxListIndex
, this is more correct. This is the only instance in the code where iteration implies the listCount from GC thread count. This inference was not an issue as the lists are inited based on the GC thread count, however now that the thread count may change, it is incorrect to assume the list count from the thread count.reinitializeGCThreadCountForRestore
j9gc_reinitializeDefaults
inmminit
, this is meant to be the top level init/verify method (e.g parsing/initing GC params based on restore cmd line opts). This is symmetrical restore call to VM startupgcInitializeDefaults
call .setMaxGCThreadCount
in Configuration Delegate to simply computation of default gc thread count at restore timeSigned-off-by: Salman Rana salman.rana@ibm.com