See 6316605 for releated discussion. CMS currently uses the
CMS token to coordinate heap resizing. For the sake of
uniformity wrt the rest of GC, it should try and replace
that use with that of the Heap_lock. This needs some
investigation as the resulting code may cause a small
performance impact and a larger code complexity impact.
The assumption, in 6316605, that the CMS token is an authoritative
proxy for the Heap_lock for the purposes of expanding the heap
turned out to be incorrect, and was flagged as an assertion failure
while expanding the heap by a mutator thread that ran out of space
in the perm gen. Recall that, for pause-time policy reasons, CMS
allows the mutator threads to expand the perm gen without reaching
a safepoint. The idea is that the Heap_lock protects such expansion.
Clearly, the CMS thread must follow the same protocol.
We are therefore converting what had originally been a clean-up RFE
targeted for Dolphin into a P2 bug-fix targeted for Mustang.
CMS token to coordinate heap resizing. For the sake of
uniformity wrt the rest of GC, it should try and replace
that use with that of the Heap_lock. This needs some
investigation as the resulting code may cause a small
performance impact and a larger code complexity impact.
The assumption, in 6316605, that the CMS token is an authoritative
proxy for the Heap_lock for the purposes of expanding the heap
turned out to be incorrect, and was flagged as an assertion failure
while expanding the heap by a mutator thread that ran out of space
in the perm gen. Recall that, for pause-time policy reasons, CMS
allows the mutator threads to expand the perm gen without reaching
a safepoint. The idea is that the Heap_lock protects such expansion.
Clearly, the CMS thread must follow the same protocol.
We are therefore converting what had originally been a clean-up RFE
targeted for Dolphin into a P2 bug-fix targeted for Mustang.
- relates to
-
JDK-6316605 atg server crashed with CMS collector
- Closed
-
JDK-6319688 Incorrect locking in CMSPermGen::mem_allocate()
- Resolved
-
JDK-6325682 VM lockup with -XX:+UseConcMarkSweepGC while loading classes with custom classloader
- Closed
-
JDK-6263371 SEGV in MarkFromRootsClosure::scanOopsInOop
- Closed