Fix reflect ConstantPool bootstrapping issues #18169
Conversation
|
jenkins compile win jdk11 |
|
jenkins test sanity alinux64 jdk21 |
Assuming the proposed extension changes are in extension repo |
|
I'm happy to go either way. We can merge it all at once, or stage it like Tobi suggests. Staging it makes it easier to test & merge version by version. |
Which changes are those? |
| if (J9_ARE_ANY_BITS_SET(vm->extendedRuntimeFlags2, J9_EXTENDED_RUNTIME2_REFLECT_CONSTANTPOOL_REGISTER_NATIVES_CALLED)) { | ||
| goto _end; | ||
| } | ||
| vm->extendedRuntimeFlags2 |= J9_EXTENDED_RUNTIME2_REFLECT_CONSTANTPOOL_REGISTER_NATIVES_CALLED; |
There was a problem hiding this comment.
What ensures this is thread-safe?
There was a problem hiding this comment.
JVM init is single threaded, so is class init.
We currently perform explicit native registration for jdk.internal.reflect.ConstantPool. This occurs after JCL init in VM startup. It is possible that ConstantPool will be used in JCL init before the natives are registered, this will result in signal 218 since we have public JNI stubs as a catch all for these capabilities. I propose the following: Step 1) (this PR) - introduce a registerNative call in ConstantPool. Step 2) - update the JCL code to use the registerNative() in the static initializer of the class, thereby ensuring that the natives are registered before the class is used. Step 3) - remove the explicit register native call With these steps we dont need to do any build coordination between openj9 and the extension repos. Signed-off-by: tajila <[email protected]>
Depends on eclipse-openj9/openj9#18169 Signed-off-by: tajila <[email protected]>
Won't we end up in the same situation we have now? |
No, this refers to the explicit call we are doing in JVM initialization |
Are you referring to this call in stdinit.c? |
yes |
Depends on eclipse-openj9/openj9#18169 Signed-off-by: tajila <[email protected]>
Depends on eclipse-openj9/openj9#18169 Signed-off-by: tajila <[email protected]>
|
@keithc-ca any further comments? |
|
Old builds (all passed):
IMO, the first set of builds should still be good. @tajila Do you agree or recommend relaunching the builds? |
|
Ill do a sanity compile since some source code was changed |
|
jenkins compile alinux64 jdk11 |
Depends on eclipse-openj9/openj9#18169 Signed-off-by: tajila <[email protected]>
Depends on eclipse-openj9/openj9#18169 Signed-off-by: tajila <[email protected]>
Depends on eclipse-openj9/openj9#18169 Signed-off-by: tajila <[email protected]>
Completes: eclipse-openj9#18169 Signed-off-by: Tobi Ajila <[email protected]>
Depends on eclipse-openj9/openj9#18169 Signed-off-by: tajila <[email protected]>
We currently perform explicit native registration for jdk.internal.reflect.ConstantPool. This occurs after JCL init in VM startup. It is possible that ConstantPool will be used in JCL init before the natives are registered, this will result in signal 218 since we have public JNI stubs as a catch all for these capabilities.
I propose the following:
Step 1) (this PR)
Step 2)
Step 3)
With these steps we dont need to do any build coordination between openj9 and the extension repos.