Do not add Own.Sync. object to the list if scan wasn't successful #21857
Conversation
This file contains hidden or 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
|
should fix #20395 |
|
This is second attempt to fix the problem, first one was reverted. A few objects have been never added to the list during Copy Forward Abort/Global GC Continuation and were discovered by followed Copy Forward and trigger an assertion.
|
|
jenkins test sanity xLinux,aix jdk21 |
|
Please correct the spelling of "successful". |
dmitripivkine
changed the title
If Ownable Synchronizer object scan has not been successful (caused Copy Forward Abort) it should not be aadded to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. Signed-off-by: Dmitri Pivkine <[email protected]>
|
jenkins test sanity xLinux,aix jdk21 |
amicic
approved these changes
May 13, 2025
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan has not been successful (caused Copy Forward Abort) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with PACKET reason and failed during the scan. It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan. Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan. Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan. Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan. Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan. Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan. Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan. Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan, but would be added on the rescan as being with PACKET reason (lost info that original scan was DIRTY_CARD). Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 20, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan, but would be (incorrectly) added on the rescan as being with PACKET reason (lost info that original scan was DIRTY_CARD). Signed-off-by: Aleksandar Micic <[email protected]>
amicic
pushed a commit
to amicic/openj9
that referenced
this pull request
May 21, 2025
If Ownable Synchronizer object scan (regardless if for PACKET or COPY reason) has not been successful (caused Copy Forward Abort, when a child object fails to copy) it should not be added to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time. The existing logic is incorrect for the case when the original scan reason was PACKET (object still a part of Collection Set) and failed to scan - the object would be added twice (both on the first and the second scan isObjectInEvacuateMemoryNoCheck condition would be true). This is a more correct variant of the first similar attempt to fix eclipse-openj9#20589, which would miss to add the object if originally scanned with COPY reason and failed during the scan - the object would neither be added on the first scan due to failed scanning nor be added on the second scan due to not being a part of CS (it's copied, in survivor memory). It is also a more correct variant of the second attempt eclipse-openj9#21857, which would incorrectly add the object if originally scanned with DIRTY_CARD (as Remembered Set, which is Root, not part of Collection Set) and failed during the scan, but would be (incorrectly) added on the rescan as being with PACKET reason (lost info that original scan was DIRTY_CARD). Signed-off-by: Aleksandar Micic <[email protected]>
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.
If Ownable Synchronizer object scan has not been successful (caused Copy Forward Abort) it should not be aadded to the list right away. This object is remembered in the work packet and is going to be rescanned for the second time.