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

John Cuthbertson john.cuthbertson at oracle.com
Fri Apr 22 17:38:23 PDT 2011


Hi EVeryone.

Typo....

On 04/22/11 17:28, John Cuthbertson wrote:
> 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.
The above paragraph should read;

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 _without_ enqueueing the 
compilation request. 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