Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8151336

Root region scanning should be cancelled and disabled when the ConcurrentMarkThread::run_service() exits

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P3 P3
    • 9
    • 9
    • hotspot
    • gc
    • b115

      The main thread is closing down the VM:

      0xffffffae08fe5138 void os::PlatformEvent::park() + 0x158
      0xffffffae08f61950 void Monitor::ILock(Thread*) + 0x180
      0xffffffae08f62a78 void Monitor::lock_without_safepoint_check(Thread*) + 0x78
      0xffffffae0913995c void SafepointSynchronize::block(JavaThread*) + 0x23c
      0xffffffae08f635d4 bool Monitor::wait(bool,long,bool) + 0x3a4
      0xffffffae093b83bc void VMThread::execute(VM_Operation*) + 0x23c
      0xffffffae089f8c68 void vm_exit(int) + 0xd8
      0xffffffae08b6caf8 JVM_Halt + 0x178
      0xffffffae07713534 Java_java_lang_Shutdown_halt0 + 0x4


      Most GC threads are waiting for work:

      0xffffffae08fd2a8c void PosixSemaphore::wait() + 0x1c
      0xffffffae093f3e38 WorkData SemaphoreGangTaskDispatcher::worker_wait_for_task() + 0x8
      0xffffffae093f2aec void GangWorker::loop() + 0x3c


      But one GC thread is in G1CMRootRegions::wait_until_scan_finished():

      0xffffffae08f63468 bool Monitor::wait(bool,long,bool) + 0x238
      0xffffffae0880f850 bool G1CMRootRegions::wait_until_scan_finished() + 0x60
      0xffffffae087e4e24 bool G1CollectedHeap::do_full_collection(bool,bool) + 0x424
      0xffffffae085fbef4 void CollectedHeap::collect_as_vm_thread(GCCause::Cause) + 0x194
      0xffffffae0938b938 void VM_CollectForMetadataAllocation::doit() + 0x368
      0xffffffae093ba144 void VM_Operation::evaluate() + 0x174
      0


      There is a bunch of threads doing:

      0xffffffae08fe5138 void os::PlatformEvent::park() + 0x158
      0xffffffae08faa0f0 void ObjectMonitor::EnterI(Thread*) + 0x3e0
      0xffffffae08fa96ec void ObjectMonitor::enter(Thread*) + 0x52c
      0xffffffae09254c34 void ObjectSynchronizer::slow_enter(Handle,BasicLock*,Thread*) + 0x2f4
      0xffffffae09254654 void ObjectSynchronizer::fast_enter(Handle,BasicLock*,bool,Thread*) + 0x194
      0xffffffae089d743c void InterpreterRuntime::monitorenter(JavaThread*,BasicObjectLock*) + 0x4cc
      0xffffffff60021f48 <interpreter> method entry point (kind = zerolocals_synchronized)
      0xffffffff60008e0c <interpreter> invoke return entry points


      And compiler threads waiting in a queue:

      0xffffffae08fe5138 void os::PlatformEvent::park() + 0x158
      0xffffffae08f61950 void Monitor::ILock(Thread*) + 0x180
      0xffffffae08f623f8 int Monitor::IWait(Thread*,long) + 0x378
      0xffffffae08f637c4 bool Monitor::wait(bool,long,bool) + 0x594
      0xffffffae0865ca14 CompileTask*CompileQueue::get() + 0x94
      0xffffffae086608e0 void CompileBroker::compiler_thread_loop() + 0x1e0


      Most other threads seems to be stopped in a safepoint:

      0xffffffae08f61950 void Monitor::ILock(Thread*) + 0x180
      0xffffffae08f62a78 void Monitor::lock_without_safepoint_check(Thread*) + 0x78
      0xffffffae091399b4 void SafepointSynchronize::block(JavaThread*) + 0x294
      0xffffffae092d09cc void JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*) + 0x19c



      The GC thread in wait_until_scan_finished() makes me wonder if this is related to JDK-8148992.

      Or this is some other intermittent problem, or a regular Solaris timeout. There are a few of those... In either case there doesn't seem to be any recent changes that would cause this, and it seems to have happened now and then for some time, so I don't think this is an integration blocker.

            brutisso Bengt Rutisson (Inactive)
            jwilhelm Jesper Wilhelmsson
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: