(0.46) Skip jitCodeCache reclamation for scavenge backout case #19664
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
jitCodeCache reclamation would be triggered by GC cycle end event, For scavenge backout case, at the end of cycle, heap would be rolled back to before scavenge cycle start, and another global GC would start right after the end of backout scavenge, so there is no need to do jitCodeCache reclamation at the end of backout scavenge. also from Java21 the partial reclamation(related with virtualThread) processing has been split to move to clearable phase of GC in order to improve the processing performance (PR:eclipse-openj9#17527), but for scavenge backout case, the backout only could happen before the first part of reclamation processing(the processing would never get a chance to run for the case), without the first part reclamation processing, the second part of reclamation processing, which triggered by GC cycle end, would be possible to reclaim the "live" stack jit frames, then cause the crash. so we need to skip jitCodeCache reclamation for scavenge backout case. - pass unsuccessful state via the cycleType of Cycle End event to the jitcodecache relamation hook for backout case. - check if unsuccessful state is set in the hook, if it is true, skip jitcodecache relamation processing(second part). Signed-off-by: hulin <[email protected]>
amicic
approved these changes
Jun 10, 2024
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.
jitCodeCache reclamation would be triggered by GC cycle end event,
For scavenge backout case, at the end of cycle, heap would be rolled
back to before scavenge cycle start, and another global GC would start
right after the end of backout scavenge, so there is no need to do
jitCodeCache reclamation at the end of backout scavenge.
also from Java21 the partial reclamation(related with virtualThread)
processing has been split to move to clearable phase of GC in order to improve the processing performance
(PR:#17527), but for scavenge backout case, the backout only could happen before the first part of reclamation processing(the processing would never get a chance to run for the case), without the first part reclamation processing, the second part of reclamation processing, which triggered by GC cycle end, would be possible to reclaim the "live" stack jit frames, then cause the crash. so we need to skip jitCodeCache reclamation for scavenge backout case.
Cherry pick #19587
Depends on eclipse-openj9/openj9-omr#208