Salt on Nursery resize #5188
Merged
Salt on Nursery resize #5188
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
Fix incorrect update of low/high Nursery bounds for Hash Salt calculation purposes. On Nursery contract, the new bounds would end up being the range of contracted area. An example: old Nursery bounds hashData1/2 ff740000/100000000 low/highAddress (range being contracted) ff740000/ff760000 new Nursery bounds hashData1/2 ff740000/ff760000 Instead, the correct new bounds of Nursery should be: ff760000/100000000 This is relatively benign problem for STW Scavenger (there would be less variety in Salt value). However, this a malign problem for Concurrent Scavenger. The salt value (hence, hash value, too) would change for objects that are allocated during active CS cycle and has been just hashed, if there was a Nursery contract at the end of that cycle. Such an object would reside in Nursery both before and after the second/last STW increment of CS cycle, but salt value would be different, because the Nursery range for Salt calculation was incorrectly updated, and that object would be incorrectly treated as out of Nursery, after the contract. Some other minor ranges in the logic is to ensure that range being contracted/expanded is always exactly at the border of exactly one of the lower or higher bound. Signed-off-by: Aleksandar Micic <amicic@ca.ibm.com>
|
jenkins compile win jdk11 |
dmitripivkine
approved these changes
Mar 21, 2019
|
Jenkins test sanity xLinux jdk8 |
|
Jenkins test sanity xLinux jdk11 |
|
Jenkins test sanity zLinux jdk8 |
|
Jenkins test sanity xLinux jdk8 |
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.
Fix incorrect update of low/high Nursery bounds for Hash Salt
calculation purposes.
On Nursery contract, the new bounds would end up being the range of
contracted area. An example:
old Nursery bounds hashData1/2 ff740000/100000000
low/highAddress (range being contracted) ff740000/ff760000
new Nursery bounds hashData1/2 ff740000/ff760000
Instead, the correct new bounds of Nursery should be: ff760000/100000000
This is relatively benign problem for STW Scavenger (there would be less
variety in Salt value). However, this a malign problem for Concurrent
Scavenger. The salt value (hence, hash value, too) would change for
objects that are allocated during active CS cycle and has been just
hashed, if there was a Nursery contract at the end of that cycle.
Such an object would reside in Nursery both before and after the
second/last STW increment of CS cycle, but salt value would be
different, because the Nursery range for Salt calculation was
incorrectly updated, and that object would be incorrectly treated as out
of Nursery, after the contract.
Some other minor ranges in the logic is to ensure that range being
contracted/expanded is always exactly at the border of exactly one of
the lower or higher bound.
Signed-off-by: Aleksandar Micic amicic@ca.ibm.com