-
Notifications
You must be signed in to change notification settings - Fork 37
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
JDK-8315478: GenShen: Tolerate round-off errors in preselected promotion budget #317
Closed
kdnilsen
wants to merge
2
commits into
openjdk:master
from
kdnilsen:tolerate-roundoff-with-preselected-promotion
+20
−1
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
So you are just adding debugging code to catch the issue more easily? (as well as the change further below)
I don't see any change in the control flow or the state here.
Is the intention to add this change and the one below to aid debugging of a very difficult to reproduce problem?
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.
ah, never mind, I see that you are adjusting some values there, which I missed in a first reading of the code.
I don't understand this logic well enough to review this change, so please go ahead an land this with the review you have from William.
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.
So effectively this is saying if
old_available < old_consumed
, makeold_available = old_consumed
so the subsequent assertion is satisfied. You are asserting that this can only happen if the difference is because of round-off errors.I do have a question about this, though. Can we avoid the round-off errors in the arithmetic entirely, by doing rounding in the "safe direction" (e.g. rounding down or up) at each step where rounding is needed, rather than relying on catching the condition and adjusting the values to re-establish the invariants?
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 would be possible to do all round-off arithmetic more conservatively, to avoid the need for this check. The "problem" arises when the sum of individual round-off errors is different than the single round-off error for the sum of promotions. My preference would be to fix this in a separate PR if we choose to do so.