<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=SV link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US>Greetings,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Kindly asking for reviews for the following bug fix/enhancement<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal>Webrev: <a href="http://cr.openjdk.java.net/~mgronlun/8039458/webrev01/">http://cr.openjdk.java.net/~mgronlun/8039458/webrev01/</a> <o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8039458">https://bugs.openjdk.java.net/browse/JDK-8039458</a> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Problem:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>VM code acquire Monitor/Mutex locks by respecting the correct lock order, which is enforced in debug builds (asserts). This is great.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>However, you could be taking locks in the correct order and everything might work just fine during development and testing (even product) but depending on runtime circumstances (load/concurrency), the way the lock(s) was acquired, i.e. the lock acquisition <i>mode</i>, can lead to very hard to debug problems (hangs/deadlocks). This is primarily related to the lock acquisition mode option “Mutex::_no_safepoint_check_flag” by which you inform your intent to respect or not-respect the safepoint protocol during lock acquisition/ownership.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><br>If a lock has already been acquired by a thread by passing the Mutex::_no_safepoint_check_flag to circumvent the safepoint protocol, the thread must *not* be allowed to attempt taking yet another lock on which it *might* block ( a lock which was not acquired by passing Mutex::_no_safepoint_check_flag in its acquisition operation), as such a lock would be participating in the safepoint protocol.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Today, doing this mistake will work just fine _<i>if the lock is currently uncontended_ </i>which it normally is in development/testing situations<b>.</b> However, once the lock then becomes contended (highly volatile pressured/concurrent product deployment) you might get the worst kind of issues to debug (hangs/deadlocks).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Naturally and as always, you have to very careful when you are taking locks using the Mutex::_no_safepoint_check_flag –however it can be very hard to determine what other code you can safely call once you are the owner of a Mutex::_no_safepoint_check_flag:ed lock - and today there is nothing but the developers attention to details that will find/help stay clear of this. I think we can do better here in enforcing some invariants in code for preempting potential deadlock prone situations.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Description:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Add debug assertions that enforce correct usages of the Mutex::_no_safepoint_check_flag when taking multiple locks.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><br>This suggestion leverages much of the existing code targeting enforcement of lock ordering- this is a simple additive change to also add invariant checking on "lock acquisition mode".<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Do note this primarily targets Java Threads running in the VM.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Also included code comment:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>/* <br> * Ensure consistency of Monitor/Mutex lock acquisitions <br> * for Java Threads running inside the VM. <br> * <br> * If a thread has already acquired lock(s) using <br> * "Mutex::_no_safepoint_check_flag" (effectively going outside the <br> * safepoint protocol), the thread should be disallowed to acquire any <br> * additional lock which _is_ participating in the safepoint protocol. <br> * <br> * If a "safepoint protocol aware" lock is contended, and the thread entering <br> * is unable to "fast acquire" the lock using cas/try_spin, <br> * it will need to block/park. Blocking on a contended lock involves a <br> * state transition and a potential SafepointSynchronize::block() call. <br> * Transitioning to a blocked state still holding "Mutex::_no_safepoint_check_flag" <br> * acquired locks is allowed, but is *very* deadlock prone. <br> * <br> * The effect of allowing this state to happen without checking is subtle <br> * and hard to debug since a problem might only appear under heavy load and <br> * only in situations with increased concurrency levels (product builds). <br> </span>* <br> */<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Testing:<o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Artificial code changes to MutexLocker and Mutex::_no_safepoint_check_flag on certain locks for detecting potential deadlock situations.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Speccjbb2005<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Kitchensink<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Thank you<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Markus<o:p></o:p></span></p></div></body></html>