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

Avoid mishandling of immutable objects that escape in cold blocks #4282

Merged
merged 1 commit into from Feb 4, 2019

Conversation

hzongaro
Copy link
Member

In fixupNode, force non-contiguous, immutable objects that escape in
cold blocks to go through fixupFieldAccess processing to ensure the
temporary that will replace it will be properly initialized.

Then, in fixupFieldAccessForNonContiguousAllocation, ensure the store
to the original object is preserved along with the store to the temporary
that's being created to replace its field. The former will be needed
if we escape, and the latter is needed if we don't escape.

Fixes: #4281

Signed-off-by: Henry Zongaro zongaro@ca.ibm.com

In fixupNode, force non-contiguous, immutable objects that escape in
cold blocks to go through fixupFieldAccess processing to ensure the
temporary that will replace it will be properly initialized.

Then, in fixupFieldAccessForNonContiguousAllocation, ensure the store
to the original object is preserved along with the store to the temporary
that's being created to replace its field.  The former will be needed
if we escape, and the latter is needed if we don't escape.

Signed-off-by:  Henry Zongaro <zongaro@ca.ibm.com>
@hzongaro
Copy link
Member Author

@vijaysun-omr Vijay, may I ask you to review this pull request?

@vijaysun-omr
Copy link
Contributor

Looks good to me @hzongaro The logic makes sense to keep both auto and field store when we have the special case of an immutable discontiguous allocation that escapes in the given block.

@hzongaro
Copy link
Member Author

Thanks, Vijay @vijaysun-omr , for all your guidance, help and advice in fixing this problem!

@andrewcraik
Copy link
Contributor

Jenkins test sanity xlinux,win,plinux jdk8,jdk11

@andrewcraik
Copy link
Contributor

Jenkins test sanity xlinux jdk11,jdk8

@DanHeidinga
Copy link
Member

This is targeted for post-0.12.0. I've assigned it to the 0.13.0 milestone so we can ensure it gets merged as soon as possible after we open up master again

@charliegracie
Copy link
Contributor

Can this be merged now?

@andrewcraik
Copy link
Contributor

I believe so - I'm happy with this given the clean sanity and review from @vijaysun-omr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Intermittent failure running ClassLibraryLambdaTest on Z
5 participants