-
Bug
-
Resolution: Fixed
-
P4
-
hs24, hs25
-
b36
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8016396 | 8 | John Cuthbertson | P4 | Resolved | Fixed | b94 |
| JDK-8033509 | 7u80 | Unassigned | P4 | Resolved | Fixed | b01 |
| JDK-8034528 | 7u65 | Unassigned | P4 | Resolved | Fixed | b01 |
| JDK-8029596 | 7u60 | Thomas Schatzl | P4 | Closed | Fixed | b05 |
The heap verification that occurs after a full GC is incorrectly placed. Currently it takes place before the RSets have been rebuilt and, hence, skips the verification of the RSets during full GCs.
This makes no sense. Many of the issues we have seen with missing barriers manifest themselves as missing rem set entries. We should be verifying that the rebuilt RSets are valid.
The RSet verification code is part of verifying a heap region and is sharedf with the verification that occurs the before GC. Verifying the RSets of a very full heap before a full GC (some of which will most likely be collected during the GC) can be very expensive I propose to only perform such a verification under control of a flag.
This makes no sense. Many of the issues we have seen with missing barriers manifest themselves as missing rem set entries. We should be verifying that the rebuilt RSets are valid.
The RSet verification code is part of verifying a heap region and is sharedf with the verification that occurs the before GC. Verifying the RSets of a very full heap before a full GC (some of which will most likely be collected during the GC) can be very expensive I propose to only perform such a verification under control of a flag.
- backported by
-
JDK-8016396 G1: Verification after a full GC is incorrectly placed.
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-