JDK-6983311 : G1: LoopTest hangs when run with -XX:+ExplicitInvokesConcurrent
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-09-09
  • Updated: 2013-09-18
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u25Fixed 7Fixed hs20Fixed
Related Reports
Relates :  
JDK-6983204 - G1: Nightly test nsk/regression/b4958615 failing with +ExplicitInvokesConcurrent
Description
The nightly test:

runtime/threads/LoopTest

is being timed out due to the test hanging.

The test result can be found at:
http://sqeweb.sfbay.sun.com/nfs/tools/gtee/results/JDK7/NIGHTLY/VM/2010-09-04/G1_GC_Baseline/vm/linux-amd64/server/mixed/linux-amd64_vm_server_mixed_vm.runtime.testlist/analysis.html

Machine: 
vm-amd64-07 (note you have to use the gtee account to login) but I've also seen it on my workstation. The hang happens quite frequently on the test system.

Test directory:
/net/sqenfs-2.sfbay/export2/results/vm/gtee/JDK7/NIGHTLY/VM/2010-09-04/G1_GC_Baseline/vm/linux-amd64/server/mixed/linux-amd64_vm_server_mixed_vm.runtime.testlist

This test is also being run with +ExplicitInvokesConcurrent.

In the test there is a Java thread that performs System.gc calls in a loop; a thread that just increments a counter in a loop; and a thread that sleeps for a specified period of time, wakes up and sets the loop termination variable for the other 2 threads.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4e0094bc41fa
09-10-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4e0094bc41fa
02-10-2010
SUGGESTED FIX Clear the "in progress" flag at the end of a marking cycle before notifying any waiter on the FullGCCount_lock. Thus if a thread requests another GC then it will not see the "in progress" flag as being set allowing another marking cycle to start.
13-09-2010
EVALUATION When ExplicitInvokesConcurrent is enabled System.gc() calls are converted to incremental evacuation pauses that trigger marking cycles. The requesting thread then waits while the initiated marking cycle is in progress. At the end of the marking cycle, the gc count is incremented; the waiting thread is notified and restarts. If another thread requests another System.gc() before the marking thread had a chance to clear its "in_progress" flag then requested GC would not initiate a marking cycle and the requesting thread would then wait for the (non-existing) marking cycle to complete - hanging the thread.
13-09-2010