<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Everyone,<br>
<br>
A new webrev that is essentially Tom's suggestion can be found at:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~johnc/7037756/webrev.2/">http://cr.openjdk.java.net/~johnc/7037756/webrev.2/</a>. I also reverted
Bengt's fix for 6789220 as, with Tom's suggested fix, a thread that
owns the pending list will no longer be blocked in
CompileBroker::compile_method_base.<br>
<br>
Testing: Ran over the weekend with the test case for 7037756; the test
case for 6789220 (which fails 50% of the time with Bengt's fix
removed); nsk tests; jprt.<br>
<br>
Thanks,<br>
<br>
JohnC<br>
<br>
<br>
On 04/22/11 18:48, Tom Rodriguez wrote:
<blockquote cite="mid:28A87274-4AAA-4F1E-9711-D722A103312E@oracle.com"
type="cite">
<pre wrap="">Instead of enshrining the reference handler thread itself, could you make it work by checking whether the requesting thread owns the reference handler lock instead? That seems more robust and targeted. Something like:
if (instanceRefKlass:owns_pending_list_lock(JavaThread::current()) {
return false;
}
replacing the fix in in CompileBroker::is_compile_blocking seems like it should work.
tom
On Apr 22, 2011, at 5:38 PM, John Cuthbertson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi EVeryone.
Typo....
On 04/22/11 17:28, John Cuthbertson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Everyone,
Can I have a couple of volunteers to look over these changes? The webrev can be found at: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~johnc/7037756/webrev.1">http://cr.openjdk.java.net/~johnc/7037756/webrev.1</a>
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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>