RFR(S): 7037756 Deadlock in compiler thread similiar to 6789220

John Cuthbertson john.cuthbertson at oracle.com
Fri Apr 22 17:28:01 PDT 2011


Hi Everyone,

Can I have a couple of volunteers to look over these changes? The webrev 
can be found at: http://cr.openjdk.java.net/~johnc/7037756/webrev.1

The issue here was very similar to the issue that caused 6789220 - the 
difference here was that the reference handler was blocked while waiting 
for the MethodCompileQueue_lock rather than waiting on a blocking 
compilation. To summarize:

Thread 6 (reference handler thread), while owning the pending list lock, 
requested a compilation and was blocked waiting on the 
MethodCompileQueue_lock.

Thread 11 (compiler thread 1), while owning the Compile_lock, attempted 
to allocate a Class mirror which triggered GC. In the GC it was blocked 
attempting to lock the pending list lock.

Thread 12 (compiler thread 2) was registering a compiled method and, 
while owning the MethodCompileQueue_lock, was blocked waiting on the 
Compile_lock.

The solution is to make the reference handler thread not block while 
holding the pending list lock. If the requesting thread is the reference 
handler thread, then an attempt is made to lock the 
MethodCompileQueue_lock in CompileBroker::compile_method_base and, if 
that is unsuccessful, we just return with enqueueing the compile task. 
Otherwise a regular blocking lock attempt is made. I also tweaked the 
fix made by Bengt for 6789220 to make all compilation requests by the 
reference handler thread non-blocking.

Testing: the failing test case has been running successfully on the 
VMSQE machine for 2 days (normally I see the deadlock after 20 minutes 
or so); the nsk tests; and a jprt job is the queue.

Thanks,

JohnC



More information about the hotspot-compiler-dev mailing list