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 to conservatively stash OSR argument info #7531

Merged
merged 1 commit into from Oct 23, 2019

Conversation

cathyzhyi
Copy link
Contributor

When stashing OSR argument info, _couldOSRAtNextBC had been used
to tell whether OSR can happen at a certain point. For post transition
OSR, when walking an potential OSR point ilgen will set
_couldOSRAtNextBC to indicate OSR could happen
at next bytecode. However, this doesn't work if the next bytecode is at
the start of another block because bytecode iterator can pick up a
different block to process. Fix to conservatively assumes OSR can
happen at any block start when stashing OSR argument info.

Signed-off-by: Yi Zhang yizhang@ca.ibm.com

When stashing OSR argument info, _couldOSRAtNextBC had been used
to tell whether OSR can happen at a certain point. For post transition
OSR, when walking an potential OSR point ilgen will set
_couldOSRAtNextBC to indicate OSR could happen
at next bytecode. However, this doesn't work if the next bytecode is at
the start of another block because bytecode iterator can pick up a
different block to process. Fix to conservatively assumes OSR can
happen at any block start when stashing OSR argument info.

Signed-off-by: Yi Zhang <yizhang@ca.ibm.com>
@andrewcraik
Copy link
Contributor

Jenkins test sanity all jdk8,jdk11

1 similar comment
@andrewcraik
Copy link
Contributor

Jenkins test sanity all jdk8,jdk11

@andrewcraik
Copy link
Contributor

Jenkins test sanity plinux jdk8

@andrewcraik
Copy link
Contributor

plinux jdk8 failure looks unrelated - rerunning to verify.

@andrewcraik
Copy link
Contributor

Looks good

@andrewcraik andrewcraik merged commit 1737549 into eclipse-openj9:master Oct 23, 2019
@andrewcraik andrewcraik added the backport:candidate Possible candidate for a backport to a `0.x.y+1` release label Oct 29, 2019
@pshipton pshipton removed the backport:candidate Possible candidate for a backport to a `0.x.y+1` release label Mar 12, 2020
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.

None yet

3 participants