comparison src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp @ 1656:4e5661ba9d98

6944166: G1: explicit GCs are not always handled correctly Summary: G1 was not handling explicit GCs correctly in many ways. It does now. See the CR for the list of improvements contained in this changeset. Reviewed-by: iveresov, ysr, johnc
author tonyp
date Mon, 28 Jun 2010 14:13:17 -0400
parents c18cbe5936b8
children f95d63e2154a
comparison
equal deleted inserted replaced
1655:e7ec8cd4dd8a 1656:4e5661ba9d98
232 // e.g. at the rate of 1 full gc per ms, this could 232 // e.g. at the rate of 1 full gc per ms, this could
233 // overflow in about 1000 years. 233 // overflow in about 1000 years.
234 GenCollectedHeap* gch = GenCollectedHeap::heap(); 234 GenCollectedHeap* gch = GenCollectedHeap::heap();
235 if (_gc_cause != GCCause::_gc_locker && 235 if (_gc_cause != GCCause::_gc_locker &&
236 gch->total_full_collections_completed() <= _full_gc_count_before) { 236 gch->total_full_collections_completed() <= _full_gc_count_before) {
237 // maybe we should change the condition to test _gc_cause ==
238 // GCCause::_java_lang_system_gc, instead of
239 // _gc_cause != GCCause::_gc_locker
240 assert(_gc_cause == GCCause::_java_lang_system_gc,
241 "the only way to get here if this was a System.gc()-induced GC");
237 assert(ExplicitGCInvokesConcurrent, "Error"); 242 assert(ExplicitGCInvokesConcurrent, "Error");
238 // Now, wait for witnessing concurrent gc cycle to complete, 243 // Now, wait for witnessing concurrent gc cycle to complete,
239 // but do so in native mode, because we want to lock the 244 // but do so in native mode, because we want to lock the
240 // FullGCEvent_lock, which may be needed by the VM thread 245 // FullGCEvent_lock, which may be needed by the VM thread
241 // or by the CMS thread, so we do not want to be suspended 246 // or by the CMS thread, so we do not want to be suspended