-
Notifications
You must be signed in to change notification settings - Fork 729
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
Fix Java 12 build failures #3980
Conversation
5aeddd7
to
1d16a0b
Compare
investigating reason for pr build failure |
c1b218b
to
2bd7ab1
Compare
update jcl version 12 to vmconstantpool.xml additions. pr build should pass |
c6577b6
to
5a98969
Compare
updated java.lang.invoke.VarHandle.VarHandleDesc stubs to throw OpenJDKCompileStubThrowError instead of UnsupportedOperationException |
I've added a commit to fix the compile errors described in #4158 to this pull request. This branch should now work again to compile Java 12. |
7148e05
to
22f0e4f
Compare
update copyright dates to 2019 |
runtime/vm/MHInterpreter.cpp
Outdated
|
||
/* [... filterHandle args descriptionBytes MethodTypeFrame filterHandle args] */ | ||
_currentThread->sp -= (filterArgSlots + 1); | ||
memcpy(_currentThread->sp, spPriorToFrameBuild, sizeof(UDATA) * (filterArgSlots+1)); |
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.
I don't think this memcpy of the arguments is actually used. There's also nothing that describes them on the stack so if they were used, we'd have a potential issue post-gc.
Can you try removing this?
runtime/vm/MHInterpreter.cpp
Outdated
*spCombinerSlot = *(spFirstFilterArgSlot - argumentTypeSlots - 1); | ||
} | ||
} | ||
_currentThread->sp = spCombinerSlot; /* after loop spCombinerSlot is at the top of the combiner arguments */ |
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.
This shouldn't be necessary as UDATA *spCombinerSlot = _currentThread->sp + filterArgSlots;
Maybe add an assert that _currentThread->sp == spCombinerSlot
?
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.
It's necessary to do this here because the sp is previously set at the number of arguments for the "next" handle after the memcpy. This sets it to the correct number of arguments for the combiner handle which might be different. I will apply this comment to the version I'm working on without the memcpy though.
UDATA *mhPtr = UNTAGGED_A0(frame); | ||
|
||
/* Advance past the frame and single argument (now filterHandle is at the top of the stack)) */ | ||
bp = (UDATA *)(((J9SFStackFrame*)(bp+1)) + 1); |
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.
This assumes that the J9SFMethodTypeFrame is immediately after the PlaceHolderFrame:
J9SFStackFrame
MethodHandle
J9SFMethodTypeFrame
I don't see how this works with the extra copy of the args from the filterArgumentsWithCombiner
method.
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.
I think the extra args in the stack comment is a mistake it should be /* [... filterHandle args descriptionBytes MethodTypeFrame filterHandle PlaceHolderFrame combinerReturnValue] */
similar to what it was in the filterArgumentsWithCombinerHandle method
Are there test cases for the new MethodHandles? In a separate PR is fine. |
Thanks for the review @DanHeidinga I've just pushed a commit that applies your changes. looking at this java.lang.System merge conflict that came up |
- new unsafe methods xxReference and natives, invokeCleaner - ImplementMethodHandle.filterArgumentsWithCombiner() - Implement MethodHandle.foldArgumentsWithCombiner() Signed-off-by: Theresa Mammarella <[email protected]>
Signed-off-by: Theresa Mammarella <[email protected]>
Fix JCL compile errors caused by changes to internal APIs Signed-off-by: Theresa Mammarella <[email protected]>
726f776
to
d8ddd09
Compare
Merged my java.lang.System changes with those for #4660 to resolve merge conflict. Confirmed that this test is still passing. |
d8ddd09
to
254822d
Compare
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.
With this change, the insertPlaceHolderFrame2
method isn't required and the change should be good to merge
runtime/vm/MHInterpreter.cpp
Outdated
Assert_VM_true(spCombinerSlot == _currentThread->sp); | ||
|
||
/* [... filterHandle args descriptionBytes MethodTypeFrame filterHandle PlaceHolderFrame combinerHandle combinerArgs] */ | ||
insertPlaceHolderFrame2(combinerArgSlots, methodHandle, J9VMJAVALANGINVOKEMETHODHANDLE_FILTERARGUMENTSWITHCOMBINERPLACEHOLDER_METHOD(_vm)); |
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.
Rather than introducing the new helper, write the combiner MH into the stack after making the placeholder frame.
insertPlaceHolderFrame(combinerArgSlots, methodHandle, J9VMJAVALANGINVOKEMETHODHANDLE_FILTERARGUMENTSWITHCOMBINERPLACEHOLDER_METHOD(_vm));
((j9object_t *)_currentThread->sp)[combinerArgSlots] = combinerHandle;
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.
updated
To be certain I don't misunderstand your comments @DanHeidinga, I've reassigned this to you to merge when you're satisfied. |
254822d
to
df6ea47
Compare
Signed-off-by: Theresa Mammarella <[email protected]>
df6ea47
to
402142b
Compare
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.
lgtm
Jenkins test sanity zlinux jdk11 |
Jenkins test sanity xlinux jdk12 |
Running a jdk12 sanity with these changes and #4531 |
Note the known issues with jdk12 sanity in https://github.com/eclipse/openj9/projects/12 |
Given the jdk11 build passed and the jdk12 compiles passed in Peter's build, I'm inclined to merge this. Any additional sanity test failures in 12 can be addressed in separate PRs |
It looks to me like the failing pr build is not actually using these changes:
|
jdk12 testing in https://ci.eclipse.org/openj9/view/Pipelines/job/Pipeline-Release-Build/40/ shows only known issues. cmdLineTester_CryptoTest_0 - openssl not ported to jdk12 yet #4658 #4661 |
Errors in java.lang.System caused by internal apis
JEP 334 stubs for Java 12 build needed for compilation
12 builds with extensions up to 0b941d8:
Fixes: #3768
Fixes: #4158
Signed-off-by: Theresa Mammarella [email protected]