<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 2014-11-13 16:36, Albert Noll wrote:<br>
    </div>
    <blockquote cite="mid:5464D003.8050907@oracle.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      Hi Nils,<br>
      <br>
      <div class="moz-cite-prefix">On 11/13/2014 03:58 PM, Albert Noll
        wrote:<br>
      </div>
      <blockquote cite="mid:5464C731.4090109@oracle.com" type="cite">Hi
        Nils, <br>
        <br>
        CompileQueue::lock() always returns MethodCompileQueue_lock (
        see init_compiler_sweeper_threads() ). It seems that your
        changes don't change existing behavior, or am I missing
        something? Note that we have 2 compilation queues, but only 1
        lock. <br>
        <br>
      </blockquote>
      It seems that I missed the most important parts of you change
      indeed. Is it right that
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(238, 238, 238);"><span class="new" style="color: blue; font-weight: bold;">Mode evaluation_mode() const { return _no_safepoint; }

</span></pre>
      makes the VM operation not execute at a safepoint? I have a
      question nevertheless. Why did you choose to return
      '_no_safepoint'  and not '_concurrent'?<br>
    </blockquote>
    <br>
    The diagnostic commands run in their own thread, and that thread
    still has to wait for the output. Running the command cuncurrently
    would require some care with how the operation is allocated so that
    it can be passed to the VM_thread and be enqueued there. <br>
    <br>
    Regards,<br>
    Nils<br>
    <br>
    <blockquote cite="mid:5464D003.8050907@oracle.com" type="cite"> <br>
      Best,<br>
      Albert<br>
      <br>
      <blockquote cite="mid:5464C731.4090109@oracle.com" type="cite">On
        11/13/2014 03:11 PM, Nils Eliasson wrote: <br>
        <blockquote type="cite">Hi, <br>
          <br>
          Please review this small change. <br>
          <br>
          1) Fixing a deadlock in diagnostic command dcmd
          print_compile_queues - between the CompileQueue_lock and
          safepointing. The CompileQueue_lock requires that we are not
          at a safepoint when taking it. Otherwise a java-thread that
          already holds the lock will block when trying to get another
          lock. In this specific case the compiler threads are Java
          threads, they take the CompileQueue_lock frequently and some
          time takes the CompileTaskAlloc_lock after that. <br>
          <br>
          Fixing this by making the diagnostic command not request a
          safepoint, <br>
          <br>
          2) Refactoring away the lock() accessor in CompileQueue and
          stating the lock explicitly. This removes an element of
          surprise and makes it easier understanding the code. <br>
        </blockquote>
        What element of surprise are you talking about? Personally, I
        prefer the current design, i.e., getting the lock by calling a
        function instead of referencing a global variable directly. If
        we ever decide to go for a 2 compile queue locks (I think that
        makes sense since we have two compilation queues), we would have
        to introduce the functions again. <br>
        <br>
        Best, <br>
        Albert <br>
        <br>
        <br>
        <blockquote type="cite">webrev: <a moz-do-not-send="true"
            class="moz-txt-link-freetext"
            href="http://cr.openjdk.java.net/%7Eneliasso/8061256/webrev.02/">http://cr.openjdk.java.net/~neliasso/8061256/webrev.02/</a>
          <br>
          bug: <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="https://bugs.openjdk.java.net/browse/JDK-8061256">https://bugs.openjdk.java.net/browse/JDK-8061256</a>
          <br>
          <br>
          Thanks, <br>
          Nils Eliasson <br>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>