Reset JNI Addresses if FSD on restore #20108
Conversation
|
@mpirvu could you please review? |
|
@dsouzai Could you also please add more info to the message of this commit. Why do we need to reset the JNI methods post restore? Are JNI methods compiled differently when debug is enable? And why only the proactive ones need to be reset? |
When I had first looked into JNI methods wrt So, "resetting" here is just reverting the |
Sure will do, however to answer the questions:
Under FSD we don't compile JNI methods. However, we do compile the JNI methods proactively in the checkpoint hook as we optimistically assume debug will not be specified on restore. If debug is specified on restore, we need to invalidate all the proactively compiled methods. Now the code currently invalidates all compiled code (including the FSD bodies) which is not very efficient, but it's a good enough solution for now. However, we don't invalidate JNI thunks because they're different. Thus, we need to reset them so that they're back to whatever the interpreter initialized them originally. |
If debug is specified on restore, ensure that any proactively compiled JNI Methods are reset to their original address. JNI methods are not compiled under FSD, but they are compiled proactively in the checkpoint hook. However, if debug is specified on restore, all proactively compiled methods, except for JNI thunks, get invalidated. Thus, the extra field of the J9Method of a JNI method needs to get reset to whatever the VM initialized them to originally. This is necessary to ensure an environment that is consistent with FSD mode. The invalidation of proactively compiled non-JNI methods (which are non-FSD bodies) ensure that non-FSD code does not execute post-restore. At the checkpoint hook, only FSD bodies are on the stacks of the threads; although the compiler currently does not reuse these FSD bodies, they will continue to execute on restore until an OSR transition, but this is OK because they are already set up for involuntary OSR. The missing piece was the JNI methods, which this commit addresses. Signed-off-by: Irwin D'Souza <[email protected]>
|
@mpirvu made requested changes. |
|
jenkins compile all jdk17 |
|
linux build failed because of |
|
jenkins test sanity zlinux,xlinux jdk17 |
|
zlinux failure due to #18048 |
|
Tests on xlinux have passed and the only failure on zlinux is due to other causes, hence merging. |
If debug is specified on restore, ensure that any proactively compiled
JNI Methods are reset to their original address.
JNI methods are not compiled under FSD, but they are compiled
proactively in the checkpoint hook. However, if debug is specified on
restore, all proactively compiled methods, except for JNI thunks, get
invalidated. Thus, the extra field of the J9Method of a JNI method
needs to get reset to whatever the VM initialized them to originally.
This is necessary to ensure an environment that is consistent with FSD
mode. The invalidation of proactively compiled non-JNI methods (which
are non-FSD bodies) ensure that non-FSD code does not execute
post-restore. At the checkpoint hook, only FSD bodies are on the stacks
of the threads; although the compiler currently does not reuse these
FSD bodies, they will continue to execute on restore until an OSR
transition, but this is OK because they are already set up for
involuntary OSR. The missing piece was the JNI methods, which this
commit addresses.