提交 a4a62971 编写于 作者: Y ysr

7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit

Summary: It turns out that there is no need to explicitly stop CMS since the JVM is taken down at a terminal safepoint during which CMS threads are (terminally) inactive. This  will need to be revised if and when we evolve in the future to a point where we allow JVM reincarnation in the same process, but those changes will be much more sweeping than just terminating CMS threads. The unused ::stop() methods will be removed in a separate CR. Also include in this CR is the fix for a small typo in the spelling of UseGCLogFileRotation in a message in arguments.cpp, brought to our attention by Rainer Jung and reviewed by minqi.
Reviewed-by: johnc, jwilhelm
上级 d2f0b980
......@@ -1690,7 +1690,7 @@ void check_gclog_consistency() {
(NumberOfGCLogFiles == 0) ||
(GCLogFileSize == 0)) {
jio_fprintf(defaultStream::output_stream(),
"To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogRotaion -XX:NumberOfGCLogFiles=<num_of_files> -XX:GCLogFileSize=<num_of_size>\n"
"To enable GC log rotation, use -Xloggc:<filename> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=<num_of_files> -XX:GCLogFileSize=<num_of_size>\n"
"where num_of_file > 0 and num_of_size > 0\n"
"GC log rotation is turned off\n");
UseGCLogFileRotation = false;
......
......@@ -468,12 +468,10 @@ void before_exit(JavaThread * thread) {
StatSampler::disengage();
StatSampler::destroy();
#ifndef SERIALGC
// stop CMS threads
if (UseConcMarkSweepGC) {
ConcurrentMarkSweepThread::stop();
}
#endif // SERIALGC
// We do not need to explicitly stop concurrent GC threads because the
// JVM will be taken down at a safepoint when such threads are inactive --
// except for some concurrent G1 threads, see (comment in)
// Threads::destroy_vm().
// Print GC/heap related information.
if (PrintGCDetails) {
......
......@@ -3698,6 +3698,14 @@ bool Threads::destroy_vm() {
// heap is unparseable if they are caught. Grab the Heap_lock
// to prevent this. The GC vm_operations will not be able to
// queue until after the vm thread is dead.
// After this point, we'll never emerge out of the safepoint before
// the VM exits, so concurrent GC threads do not need to be explicitly
// stopped; they remain inactive until the process exits.
// Note: some concurrent G1 threads may be running during a safepoint,
// but these will not be accessing the heap, just some G1-specific side
// data structures that are not accessed by any other threads but them
// after this point in a terminal safepoint.
MutexLocker ml(Heap_lock);
VMThread::wait_for_vm_thread_exit();
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册