Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2188367 | 6-pool | Unassigned | P2 | Closed | Won't Fix |
The original problem, reported in 6442774, was that after a GC thread yields, the mutator thread that requested the yield might not get a chance to run and actually did what it needed to do. Therefore, the GC thread could complete the yield without the requesting mutator thread actually doing what it needed to do. This could cause the mutator thread to be blocked for a long time and the GC thread doing frequent yields, which slowed it down.
The fix for 6442774 was conservative and causes the GC thread to sleep while looping for a period of time, while waiting for the mutator thread to wake up. A better fix will be to improve the interaction between yielding GC and mutator threads by using wait/notify.
The fix for 6442774 was conservative and causes the GC thread to sleep while looping for a period of time, while waiting for the mutator thread to wake up. A better fix will be to improve the interaction between yielding GC and mutator threads by using wait/notify.
- backported by
-
JDK-2188367 Revisit GC / app thread interaction in CMS during GC yielding
- Closed
- relates to
-
JDK-6442774 CMS cycle blocks a direct old gen allocation and is slow
- Resolved
-
JDK-6692906 CMS: parallel concurrent marking may be prone to hanging or stalling mutators for periods of time
- Closed