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
Introduce JVMPortableRestoreMode #18252
Conversation
@dsouzai is there a way to turn on JIT logging to confirm it is generating portable JIT code? |
I don't see any logging. What you could do is something like this:
|
808cf78
to
6d36d29
Compare
The definition of
which means that it'll return true if |
4659938
to
92cb024
Compare
Ya, Ive corrected that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM; just requesting a couple of changes.
49b6ae5
to
d6fc5fb
Compare
Oh! I just recalled, you also need to change the |
9eb7071
to
e3f09e4
Compare
Ready for another look |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor changes requested.
Previously, the CRIURestoreNonPortableMode was used to determine if a checkpoint could be taken after restore. If CRIURestoreNonPortableMode was enabled (default mode) only a single checkpoint is allowed and the JVM doesn't need to generate portable code upon restore. This capability also allows the JVM to use standard security providers since there is no risk for that state to be serialized. There is a need to separate out the portability capabilites and the behavioural changes that CRIURestoreNonPortableMode offers. There are cases where one wants portability as well as standard security capabilites for debugging purposes. This PR separates out the portability capabilites and the behavioural aspects by providing an option that forces portability upon restore regardless of what CRIURestoreNonPortableMode is set to. In the future we can add another option that forces portability in non-CRIU mode, it its desired. Signed-off-by: Tobi Ajila <atobia@ca.ibm.com>
Ready for another look |
jenkins test sanity all jdk17,jdk21 |
All test passed in the windows run, just an infra issue: https://openj9-jenkins.osuosl.org/job/Test_openjdk17_j9_sanity.functional_x86-64_windows_Personal/315/tapResults/.
|
Previously, the CRIURestoreNonPortableMode was used to determine if a checkpoint could be taken after restore. If CRIURestoreNonPortableMode was enabled (default mode) only a single checkpoint is allowed and the JVM doesn't need to generate portable code upon restore. This capability also allows the JVM to use standard security providers since there is no risk for that state to be serialized.
There is a need to separate out the portability capabilites and the behavioural changes that CRIURestoreNonPortableMode offers. There are cases where one wants portability as well as standard security capabilites for debugging purposes.
This PR separates out the portability capabilites and the behavioural aspects by providing an option that forces portability upon restore regardless of what CRIURestoreNonPortableMode is set to.
In the future we can add another option that forces portability in non-CRIU mode, it its desired.