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

JIT common and x86 support for constant dynamic #2754

Merged
merged 1 commit into from
Sep 14, 2018

Conversation

yanluo7
Copy link
Contributor

@yanluo7 yanluo7 commented Aug 30, 2018

Signed-off-by: Yan Luo Yan_Luo@ca.ibm.com

@yanluo7
Copy link
Contributor Author

yanluo7 commented Aug 30, 2018

OMR dependency: eclipse-omr/omr#2912
Design documentation is detailed in #2307

@yanluo7
Copy link
Contributor Author

yanluo7 commented Aug 30, 2018

@cathyzhyi Could you do a review?

@yanluo7
Copy link
Contributor Author

yanluo7 commented Aug 31, 2018

Travis CI build failure is expected due to OMR dependency change.

@DanHeidinga DanHeidinga added the depends:omr Pull request is dependent on a corresponding change in OMR label Sep 5, 2018
@yanluo7 yanluo7 force-pushed the condy branch 6 times, most recently from 10fe200 to e3ae231 Compare September 9, 2018 15:45
// Else if second slot is Void.class, the CP entry is resolved to null (0) value.
// Other casese, the CP entry is considered unresolved.
bool
TR_ResolvedJ9Method::isUnresolvedConstantDynamic(I_32 cpIndex)
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the first slot represent the value of the condy and the second slot represent the resolved class of the condy? Maybe it's better to say this explicitly in the comment to avoid confusion especially when the name of the second slot is called exception.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Both value and exception slots are of object pointer type. If first slot is non null, the CP entry is resolved to a non-null value. Else if second slot is the class object of j/l/Void, the CP entry is resolved to null (0) value. We retrieve the Void class object via javaVM->voidReflectClass->classObject, which is protected by VMAccessCrtiticalSection to ensure vm access. Other cases, the CP entry is considered unresolved. Added VMAccessCrtiticalSection code and more comments.

@irinarada
Copy link

@yanluo7 , @cathyzhyi any ETA for the latest changes? This blocks the z delivery part. @fjeremic , @gita-omr @andrewcraik

@yanluo7 yanluo7 force-pushed the condy branch 3 times, most recently from 70f9541 to 140cf1b Compare September 11, 2018 16:05
@andrewcraik
Copy link
Contributor

@yanluo7 asked me to review this yesterday - I have just arrived back from vacation so I will try and do a review today. If the review goes well the merge should be very soon, but I would target end of the week.

bool
TR_ResolvedJ9Method::isConstantDynamic(I_32 cpIndex)
{
TR_ASSERT(cpIndex != -1, "cpIndex shouldn't be -1");
Copy link
Contributor

Choose a reason for hiding this comment

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

This should probably be an TR_ASSERT_FATAL - it will never work with cpIndex -1, it doesn't handle the case, and it is just plain wrong to call it with -1. The check is cheap so keeping it in at runtime will make sure we don't miss a bad use of this API.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this method should have fatal assertion as this query is the entry point of JIT condy processing logic.

void *
TR_ResolvedJ9Method::dynamicConstant(I_32 cpIndex)
{
TR_ASSERT(cpIndex != -1, "cpIndex shouldn't be -1");
Copy link
Contributor

Choose a reason for hiding this comment

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

same thing for this one

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added fatal assertion here.

{
char *autoboxClassSig = NULL;
int32_t autoboxClassSigLength = 0;
switch (returnTypeUtf8Data[0])
Copy link
Contributor

Choose a reason for hiding this comment

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

There should be an assert above this to make sure the signature is valid - ie 1 char.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here we are inside the if (isCondyPrimitive) condition so it's already implicitly ensured that turnTypeUtf8Length is 1 for the type signature UTF8 : bool isCondyPrimitive = (1 == returnTypeUtf8Length);

valueOffset = comp()->fej9()->getObjectHeaderSizeInBytes()
+ comp()->fej9()->getInstanceFieldOffset(typeClassBlock, "value", 5, "Z", 1);
break;
default:
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't this assert?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, added a fatal assertion for unrecognized type signature.

@andrewcraik
Copy link
Contributor

@yanluo7 the new methods need doxygen comments to describe their operation, their inputs and their return values as well as anything else people using the API need to know / be aware of

@yanluo7 yanluo7 force-pushed the condy branch 2 times, most recently from 37c2667 to 1a803cb Compare September 12, 2018 15:56
loadConstant(TR::dconst, *(double*)(obj+valueOffset));
break;
default:
break;
Copy link
Contributor

Choose a reason for hiding this comment

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

need an assert here too to match the case above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added assertion.

dt = TR::Int32;
break;
default:
break;
Copy link
Contributor

Choose a reason for hiding this comment

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

Also needs an assert

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added assertion.

@andrewcraik
Copy link
Contributor

Jenkins test sanity all jdk11

@andrewcraik
Copy link
Contributor

Ok I think that looks good - will let sanity run and then I think this should be good to go.

@fjeremic
Copy link
Contributor

We're waiting for an OMR-Acceptance promotion due to a bad OMR merge causing mutual dependencies for Z codny support. Sorry about that. You can launch a Jenkinds depends build against eclipse/omr#master though. That should work fine.

@andrewcraik
Copy link
Contributor

Jenkins test sanity all jdk11 depends eclipse/omr#master

@andrewcraik
Copy link
Contributor

@fjeremic thanks we'll do that - my bad for not noticing since I've been busy with non-openj9 things

Signed-off-by: Yan Luo <Yan_Luo@ca.ibm.com>
@yanluo7
Copy link
Contributor Author

yanluo7 commented Sep 13, 2018

Added missing ExternHelper declaration that should address windows compile.

@andrewcraik
Copy link
Contributor

Jenkins test sanity all jdk11 depends eclipse/omr#master

@andrewcraik
Copy link
Contributor

@yanluo7 can you take a look at sanity and see if the failures are of concern in your opinion - I will look at them separately and see if we agree

@yanluo7
Copy link
Contributor Author

yanluo7 commented Sep 13, 2018

@andrewcraik
The test failures are summarized here:
win_x86-64_cmprssptrs & linux_x86-64_cmprssptrs : Nestmate_virtual_private_0
linux_x86-64: jsr335_interfacePrivateMethod and Nestmate_virtual_private
linux_390-64_cmprssptrs : org.openj9.test.java.lang.Test_String.test_toLowerCase_lithuanian and
java.lang.ClassFormatError: JVMCFRE145 Nest host must be a constant class; There seems to be a few NEST-related failures here.

The entry point to all the constant dynamic logic gated by TR_ResolvedJ9Method::isConstantDynamic(cpIndex), which checks whether the given CP type is J9CPTYPE_CONSTANT_DYNAMIC , it should not kick in for all of these tests as they don't have constant dynamics in them.

@andrewcraik
Copy link
Contributor

@yanluo7 I agree - there don't seem to be constant dynamic failures in the above so I will merge this.

@andrewcraik andrewcraik merged commit 63bd3cc into eclipse-openj9:master Sep 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
depends:omr Pull request is dependent on a corresponding change in OMR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants