<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-14 10:59, Albert Noll wrote:<br>
    </div>
    <blockquote cite="mid:5465D284.2010506@oracle.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      Hi Nils,<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 11/14/2014 10:43 AM, Nils Eliasson
        wrote:<br>
      </div>
      <blockquote cite="mid:5465CEC0.3040707@oracle.com" type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        <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>
      </blockquote>
      Thanks for the explanation.<br>
    </blockquote>
    <br>
    Thanks for taking a look at this,<br>
    //Nils<br>
    <br>
    <blockquote cite="mid:5465D284.2010506@oracle.com" type="cite"> <br>
      Best,<br>
      Albert<br>
      <blockquote cite="mid:5465CEC0.3040707@oracle.com" type="cite">
        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>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>