Skip to content
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

Merged
merged 4 commits into from
Feb 14, 2019
Merged

Conversation

theresa-m
Copy link
Contributor

@theresa-m theresa-m commented Dec 10, 2018

Errors in java.lang.System caused by internal apis

JEP 334 stubs for Java 12 build needed for compilation

  • stubs for java.lang.Class
  • stubs for java.lang.invoke.VarHandle.VarHandleDesc

12 builds with extensions up to 0b941d8:

  • new unsafe methods xxReference and natives, invokeCleaner
  • MethodHandle.filterArgumentsWithCombiner()
  • MethodHandle.foldArgumentsWithCombiner()

Fixes: #3768
Fixes: #4158

Signed-off-by: Theresa Mammarella [email protected]

@theresa-m theresa-m force-pushed the working_12 branch 2 times, most recently from 5aeddd7 to 1d16a0b Compare December 10, 2018 20:49
@theresa-m theresa-m changed the title 12 builds with extensions up to 0b941d8 Fix Java 12 build failures Dec 11, 2018
@theresa-m
Copy link
Contributor Author

investigating reason for pr build failure

@theresa-m theresa-m force-pushed the working_12 branch 2 times, most recently from c1b218b to 2bd7ab1 Compare December 11, 2018 16:41
@theresa-m
Copy link
Contributor Author

update jcl version 12 to vmconstantpool.xml additions. pr build should pass

@theresa-m theresa-m force-pushed the working_12 branch 2 times, most recently from c6577b6 to 5a98969 Compare December 12, 2018 21:23
@theresa-m
Copy link
Contributor Author

updated java.lang.invoke.VarHandle.VarHandleDesc stubs to throw OpenJDKCompileStubThrowError instead of UnsupportedOperationException

@theresa-m
Copy link
Contributor Author

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.

@theresa-m theresa-m force-pushed the working_12 branch 2 times, most recently from 7148e05 to 22f0e4f Compare January 8, 2019 15:24
@theresa-m
Copy link
Contributor Author

update copyright dates to 2019


/* [... filterHandle args descriptionBytes MethodTypeFrame filterHandle args] */
_currentThread->sp -= (filterArgSlots + 1);
memcpy(_currentThread->sp, spPriorToFrameBuild, sizeof(UDATA) * (filterArgSlots+1));
Copy link
Member

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 Show resolved Hide resolved
*spCombinerSlot = *(spFirstFilterArgSlot - argumentTypeSlots - 1);
}
}
_currentThread->sp = spCombinerSlot; /* after loop spCombinerSlot is at the top of the combiner arguments */
Copy link
Member

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?

Copy link
Contributor Author

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);
Copy link
Member

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.

Copy link
Contributor Author

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

@DanHeidinga
Copy link
Member

Are there test cases for the new MethodHandles? In a separate PR is fine.

@theresa-m
Copy link
Contributor Author

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]>
@theresa-m
Copy link
Contributor Author

theresa-m commented Feb 13, 2019

Merged my java.lang.System changes with those for #4660 to resolve merge conflict. Confirmed that this test is still passing.

Copy link
Member

@DanHeidinga DanHeidinga left a 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

Assert_VM_true(spCombinerSlot == _currentThread->sp);

/* [... filterHandle args descriptionBytes MethodTypeFrame filterHandle PlaceHolderFrame combinerHandle combinerArgs] */
insertPlaceHolderFrame2(combinerArgSlots, methodHandle, J9VMJAVALANGINVOKEMETHODHANDLE_FILTERARGUMENTSWITHCOMBINERPLACEHOLDER_METHOD(_vm));
Copy link
Member

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;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

@keithc-ca keithc-ca assigned DanHeidinga and unassigned keithc-ca Feb 13, 2019
@keithc-ca
Copy link
Contributor

To be certain I don't misunderstand your comments @DanHeidinga, I've reassigned this to you to merge when you're satisfied.

Signed-off-by: Theresa Mammarella <[email protected]>
Copy link
Member

@DanHeidinga DanHeidinga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@DanHeidinga
Copy link
Member

Jenkins test sanity zlinux jdk11

@DanHeidinga
Copy link
Member

Jenkins test sanity xlinux jdk12

@pshipton
Copy link
Member

Running a jdk12 sanity with these changes and #4531
https://ci.eclipse.org/openj9/view/Pipelines/job/Pipeline-Release-Build/40/

@pshipton
Copy link
Member

Note the known issues with jdk12 sanity in https://github.com/eclipse/openj9/projects/12

@DanHeidinga
Copy link
Member

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

@theresa-m
Copy link
Contributor Author

It looks to me like the failing pr build is not actually using these changes:

17:12:28 Using OPENJ9_REPO = https://github.com/eclipse/openj9.git OPENJ9_BRANCH = master OPENJ9_SHA = 89b39276bc647c6eafa5127db9dd3e3040e9a72b

@pshipton
Copy link
Member

pshipton commented Feb 14, 2019

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
TestFlushReflectionCache_0

#4661
openj9_jsr292Test_0
openj9_jsr292Test_JitCount0_0

@pshipton pshipton merged commit 7ce88fd into eclipse-openj9:master Feb 14, 2019
@theresa-m theresa-m deleted the working_12 branch February 25, 2019 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants