| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2219003 | 8 | Tony Printezis | P3 | Resolved | Fixed | b18 |
| JDK-2219047 | 7u4 | Tony Printezis | P3 | Closed | Fixed | b05 |
We see every now and then G1 decreasing the eden size to the minimum for a while without apparent reason and keeping it there for a few GCs before things get back to normal.
It looks as if the issue is an integer overflow (underflow?) during this calculation:
size_t rs_length_diff = _max_rs_lengths - _recorded_rs_lengths;
It looks as if _max_rs_lengths is smaller than _recorded_rs_lengths, rs_length_diff (being an unsigned value) gets _very_ large, and the prediction way overpredict.
Many thanks for Thomas Schatzl who, once again, tracked this down.
It looks as if the issue is an integer overflow (underflow?) during this calculation:
size_t rs_length_diff = _max_rs_lengths - _recorded_rs_lengths;
It looks as if _max_rs_lengths is smaller than _recorded_rs_lengths, rs_length_diff (being an unsigned value) gets _very_ large, and the prediction way overpredict.
Many thanks for Thomas Schatzl who, once again, tracked this down.
- backported by
-
JDK-2219003 G1: eden size unnecessarily drops to the minimum
-
- Resolved
-
-
JDK-2219047 G1: eden size unnecessarily drops to the minimum
-
- Closed
-
- relates to
-
JDK-7119027 G1: use atomics to update RS length / predict time of inc CSet
-
- Closed
-