Fix GC crash when running portable code on PWR10 CPUs - #17964
Merged
Conversation
When running portable code (CRIU or PortableAOT) on PWR10 CPUs and a method needs to save all non-volatile registers so that GC has access to them (i.e. methods with a Direct-to-JNI call-out) this issue can occur. 1) The portable code will be compiled for PWR8 and therefor does not save R16 since it is dedicated to the PTOC and therefore can never contain a collectible obj ref. 2) A method lower on the stack could have been compiled for PWR10 and used R16 to hold a collectible obj ref. Now if a GC cycle occurs while executing in the JNI code, the GC will retrieve the saved non-volatile registers from the frame of the portable code method (R17-R31). Then it walks the stack looking for collectible references. When it encounters a frame for a PWR10 compiled method that has marked R16 as collectible it will look at its register set and try to access R16. Since the portable code did not save R16 it gets a null reference and crashes. This fix will force portable code that saves all non-volatile registers for the GC to save and restore R16 even when the target CPU is less then PWR10. In this way, should the portable code be executed on a PWR10 CPU, it will have saved R16 in case some frame down the stack from the portable code's frame uses R16 to hold a collectible obj reference. Signed-off-by: Kevin Langman <langman@ca.ibm.com>
Contributor
|
Jenkins test sanity plinux,aix jdk8,jdk11 |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
When running portable code (CRIU or PortableAOT) on PWR10 CPUs and a method needs to save all non-volatile registers so that GC has access to them (i.e. methods with a Direct-to-JNI call-out) this issue can occur. 1) The portable code will be compiled for PWR8 and therefor does not save R16 since it is dedicated to the PTOC and therefore can never contain a collectible obj ref. 2) A method lower on the stack could have been compiled for PWR10 and used R16 to hold a collectible obj ref. Now if a GC cycle occurs while executing in the JNI code, the GC will retrieve the saved non-volatile registers from the frame of the portable code method (R17-R31). Then it walks the stack looking for collectible references. When it encounters a frame for a PWR10 compiled method that has marked R16 as collectible it will look at its register set and try to access R16. Since the portable code did not save R16 it gets a null reference and crashes.
This fix will force portable code that saves all non-volatile registers for the GC to save and restore R16 even when the target CPU is less then PWR10. In this way, should the portable code be executed on a PWR10 CPU, it will have saved R16 in case some frame down the stack from the portable code's frame uses R16 to hold a collectible obj reference.