Collector STW flag #5131
Merged
Collector STW flag #5131
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
Generalize the existing flag that was being set only in Concurrent Global GC to being maintained by base Collector, so that can be used for any STW Collector. Specifically, it was needed in an unusual combination when Concurrent Scavenger was enabled, but Concurrent Mark disabled (so Global GC was not MM_ConcurrentGC, but MM_ParallelGlobalGC which would not set STW flag), and when CS would abort and Global Marking would miss to fixup forwarded slots (during STW phase). In future, the flag might be useful for other code in CS & Balanced to determine if GC threads running in STW or concurrent phase. But for that we have to properly set it for cases when Master Threads is explicit. This is better to do in a separate change, if/when it becomes important. For now, this flag is reliable only any STW GC with implicit Master Thread. This is a slightly adjusted variant of eclipse-omr#5112 that had a problem with setting this flag before completeExternalConcurrentCycle(). While in theory that would be ok, heap resizing code in ConcurrentGC would (somewhat incorrectly) rely on _stwCollectionInProgress being now true to conclude that resizing request was not coming from overlapping Scavenger (thinking that it's not possible that both Global and Scavenger could be STW at the same time). That code is just way too risky to change, hence we keep the old behavior where _stwCollectionInProgress for global GC is false while completeExternalConcurrentCycle is in progress, and set it to true marginally later, just after completeExternalConcurrentCycle is complete. Signed-off-by: Aleksandar Micic <amicic@ca.ibm.com>
amicic
force-pushed
the
collector_stw_flag
branch
from
cebcec1
to
4e30ec3
Compare
|
@genie-omr build all |
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.
Generalize the existing flag that was being set only in Concurrent
Global GC to being maintained by base Collector, so that can be used
for any STW Collector.
Specifically, it was needed in an unusual combination when Concurrent
Scavenger was enabled, but Concurrent Mark disabled (so Global GC was
not MM_ConcurrentGC, but MM_ParallelGlobalGC which would not set STW
flag), and when CS would abort and Global Marking would miss to fixup
forwarded slots (during STW phase).
In future, the flag might be useful for other code in CS & Balanced to
determine if GC threads running in STW or concurrent phase. But for that
we have to properly set it for cases when Master Threads is explicit.
This is better to do in a separate change, if/when it becomes important.
For now, this flag is reliable only any STW GC with implicit Master
Thread.
This is a slightly adjusted variant of
#5112 that had a problem with setting
this flag before completeExternalConcurrentCycle(). While in theory that
would be ok, heap resizing code in ConcurrentGC would (somewhat
incorrectly) rely on _stwCollectionInProgress being now true to conclude
that resizing request was not coming from overlapping Scavenger
(thinking that it's not possible that both Global and Scavenger could be
STW at the same time). That code is just way too risky to change, hence
we keep the old behavior where _stwCollectionInProgress for global GC is
false while completeExternalConcurrentCycle is in progress, and set it
to true marginally later, just after completeExternalConcurrentCycle is
complete.
Signed-off-by: Aleksandar Micic amicic@ca.ibm.com