Do not version w.r.t. concurrently writable memory #33
Conversation
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
Versioner currently treats loads of fields and statics as loop-invariant (when the loop doesn't explicitly write them) and generates versioning tests containing such loads. If another thread writes to a field or static, it's possible for the value observed by the loop body to differ from the value observed in a versioning test. For a load that has been copied into multiple versioning tests, it is even possible to see values that are inconsistent between versioning tests. In particular, after running a versioning test, the property it tests for may no longer hold of the value obtained by repeating the load, so it is incorrect to skip checks. In the absence of synchronization and calls it is possible to version based on expressions containing such loads by privatizing their values, guaranteeing that the values remain stable throughout the series of versioning tests and the hot loop body. However, doing so is a very large change. For now, treat any node that would need to be privatized as non-invariant to prevent incorrect versioning. Signed-off-by: Devin Papineau <devinmp@ca.ibm.com>
pshipton
approved these changes
Jul 17, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Versioner currently treats loads of fields and statics as loop-invariant (when the loop doesn't explicitly write them) and generates versioning tests containing such loads. If another thread writes to a field or static, it's possible for the value observed by the loop body to differ from the value observed in a versioning test. For a load that has been copied into multiple versioning tests, it is even possible to see values that are inconsistent between versioning tests. In particular, after running a versioning test, the property it tests for may no longer hold of the value obtained by repeating the load, so it is incorrect to skip checks.
In the absence of synchronization and calls it is possible to version based on expressions containing such loads by privatizing their values, guaranteeing that the values remain stable throughout the series of versioning tests and the hot loop body. However, doing so is a very large change.
For now, treat any node that would need to be privatized as non-invariant to prevent incorrect versioning.
The upstream OMR PR eclipse-omr/omr#4138 has been merged. The parent of that commit was too new, so here the change has been rebased onto v0.15.0-release.