| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2176726 | 7 | Igor Veresov | P3 | Closed | Fixed | b03 |
| JDK-2171778 | 6u4 | Igor Veresov | P3 | Resolved | Fixed | b03 |
CMSIncrementalMode currently uses certain young gen allocation
point threshold crossings to act as the strobe to enable and
disable the CMS work. ExplicitGCInvokesConcurrent runs CMS
when asked to full gc. If there's an application where,
for example, all activity is stopped while a single thread
invokes System.gc(), then we have a circular deadlock --
the System.gc() call will (by design) not return
until the old gen collection is completed by the CMS thread.
In turn the CMS thread will not start the collection cycle
unless there is allocation activity in the young gen that
will strobe it.
We need to fix this mal-interaction of the two features.
###@###.### 2005-06-06 16:51:58 GMT
point threshold crossings to act as the strobe to enable and
disable the CMS work. ExplicitGCInvokesConcurrent runs CMS
when asked to full gc. If there's an application where,
for example, all activity is stopped while a single thread
invokes System.gc(), then we have a circular deadlock --
the System.gc() call will (by design) not return
until the old gen collection is completed by the CMS thread.
In turn the CMS thread will not start the collection cycle
unless there is allocation activity in the young gen that
will strobe it.
We need to fix this mal-interaction of the two features.
###@###.### 2005-06-06 16:51:58 GMT
- backported by
-
JDK-2171778 CMS: +ExplicitGCInvokesConcurrent can hang when +CMSIncrementalMode
-
- Resolved
-
-
-
- Closed
-
- relates to
-
JDK-5025281 Allow System.gc() to trigger concurrent (not stop-the-world) full collections
-
- Resolved
-