-
Enhancement
-
Resolution: Fixed
-
P3
-
hs19
-
b12
-
generic
-
generic
-
Not verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2220625 | 8 | Bengt Rutisson | P3 | Resolved | Fixed | b24 |
| JDK-2220561 | 7u4 | Bengt Rutisson | P3 | Closed | Fixed | b10 |
Currently, we only decide whether to initiate a marking cycle at the end of an evacuation pause. This works well most of the time. However, if an application performs a lot of humongous object allocations the heap could grow quite rapidly but we will not initiate a marking cycle unless we also do an evacuation pause. This might cause a Full GC which we might be able to prevent if we initiated a marking cycle during the humongous allocations.
This CR proposes to extend the humongous object allocation path to also check the heap occupancy and initiate a marking cycle when / if needed. Given that in G1 we can only initiate marking cycles after doing an evacuation pause, we'll probably have to schedule an evacuation pause with a piggy-backed initial-mark for the marking cycle to start.
This CR proposes to extend the humongous object allocation path to also check the heap occupancy and initiate a marking cycle when / if needed. Given that in G1 we can only initiate marking cycles after doing an evacuation pause, we'll probably have to schedule an evacuation pause with a piggy-backed initial-mark for the marking cycle to start.
- backported by
-
JDK-2220625 G1: humongous object allocations should initiate marking cycles when necessary
-
- Resolved
-
-
-
- Closed
-
- relates to
-
JDK-7158682 G1: Handle leak when running nsk.sysdict tests
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-