<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Albert pointed out that there are actually only one compile queue
    lock share by the queues. That simplified the patch.<br>
    <br>
    Next: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~neliasso/8058461/webrev.12">http://cr.openjdk.java.net/~neliasso/8058461/webrev.12</a><br>
    <br>
    Thanks,<br>
    //Nils<br>
    <br>
    <div class="moz-cite-prefix">On 2014-09-18 12:41, Nils Eliasson
      wrote:<br>
    </div>
    <blockquote cite="mid:541AB6EA.7080809@oracle.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      Yes, good catch.<br>
      <br>
      Next: <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://cr.openjdk.java.net/%7Eneliasso/8058461/webrev.09/">http://cr.openjdk.java.net/~neliasso/8058461/webrev.09/</a><br>
      <br>
      //Nils<br>
      <br>
      <div class="moz-cite-prefix">On 2014-09-18 12:21, Albert wrote:<br>
      </div>
      <blockquote cite="mid:541AB23E.6020800@oracle.com" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        Hi Nils,<br>
        <br>
        <meta http-equiv="content-type" content="text/html;
          charset=windows-1252">
        <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;"> 785 void CompileBroker::print_compile_queues(outputStream* st) {
 786   _c1_compile_queue->print_with_lock(st);
 787   _c2_compile_queue->print_with_lock(st);
 788 }


</pre>
        can't it happen that _c1_compile_queue and/or _c2_compile_queue
        or NULL?<br>
        <br>
        Best,<br>
        Albert<br>
        <br>
         <br>
        <div class="moz-cite-prefix">On 09/18/2014 10:50 AM, Nils
          Eliasson wrote:<br>
        </div>
        <blockquote cite="mid:541A9CB8.5050801@oracle.com" type="cite">Yes.


          Also good to have the print method lock-free so it can be
          callled from a debugger without hassle. Adding a wrapper that
          takes the compileQueue lock. <br>
          <br>
          New webrev: <a moz-do-not-send="true"
            class="moz-txt-link-freetext"
            href="http://cr.openjdk.java.net/%7Eneliasso/8058461/webrev.08/">http://cr.openjdk.java.net/~neliasso/8058461/webrev.08/</a>
          <br>
          <br>
          Thanks! <br>
          //Nils <br>
          <br>
          On 2014-09-18 02:59, Vladimir Kozlov wrote: <br>
          <blockquote type="cite">CompileQueue::add() path already has
            lock acquired. <br>
            I think you need the lock only in
            CompileBroker::print_compile_queues(). <br>
            <br>
            Thanks, <br>
            Vladimir <br>
            <br>
            On 9/17/14 1:54 AM, Nils Eliasson wrote: <br>
            <blockquote type="cite"> <br>
              Hi Albert, <br>
              <br>
              On 2014-09-16 10:45, Albert wrote: <br>
              <blockquote type="cite">Hi Nils, <br>
                <br>
                please see comments inline. <br>
                <br>
                On 09/16/2014 10:16 AM, Nils Eliasson wrote: <br>
                <blockquote type="cite">Hi, <br>
                  <br>
                  I would like review of this change that includes three
                  fixes: <br>
                  <br>
                  1) Let Dcmd Compiler.codelist only print
                  alive-nmethods. We ran into <br>
                  crashes when listing zombies and unloaded too. Alive
                  nmethods <br>
                  includes not-entrants so it still gives a pretty good
                  idea about <br>
                  whats in the code cache and what has been used
                  recently. <br>
                  <br>
                </blockquote>
                What was the cause of these crashes? Is the reason that
                <br>
                nmethod->method() is null? <br>
              </blockquote>
              <br>
              In one case it crashed when
              nmethod->method()->constants() was null when <br>
              printing the name. <br>
              <br>
              I see that the segmented code cache push already changed
              to only <br>
              iterating the alive nmethods so I removed that from the
              patch. <br>
              <br>
              <blockquote type="cite">Would it make sense to print
                information about zombie methods that <br>
                don't lead <br>
                to a crash? <br>
              </blockquote>
              Probably not. Not_entrant nmethods may stay around for a
              while, but once <br>
              zombies they are reclaimed pretty fast. <br>
              <br>
              <blockquote type="cite"> <br>
                <br>
                <blockquote type="cite">2) Take CompileQueue lock when
                  printing queue. It is not enough to be <br>
                  at a safepoint - the compiler threads may still mutate
                  the list <br>
                  causing crashes. <br>
                  <br>
                </blockquote>
                Are we guaranteed to not run into a deadlock when we
                acquire the lock? <br>
              </blockquote>
              <br>
              Yes. It doesn't use any other lock. <br>
              <br>
              New webrev: <a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="http://cr.openjdk.java.net/%7Eneliasso/8058461/webrev.05/">http://cr.openjdk.java.net/~neliasso/8058461/webrev.05/</a>
              <br>
              <br>
              Thanks Albert and Christian for your feedback. <br>
              <br>
              //Nils <br>
              <br>
              <blockquote type="cite"> <br>
                Best, <br>
                Albert <br>
                <blockquote type="cite">3) Relax the parsing of long
                  hex-numbers in the test of codelist. <br>
                  High addresses (sparc) casues NumberFormatExceptions.
                  <br>
                  <br>
                  bug: <a moz-do-not-send="true"
                    class="moz-txt-link-freetext"
                    href="https://bugs.openjdk.java.net/browse/JDK-8058461">https://bugs.openjdk.java.net/browse/JDK-8058461</a>
                  <br>
                  webrev: <a moz-do-not-send="true"
                    class="moz-txt-link-freetext"
                    href="http://cr.openjdk.java.net/%7Eneliasso/8058461/webrev.04/">http://cr.openjdk.java.net/~neliasso/8058461/webrev.04/</a>
                  <br>
                  <br>
                  Thanks! <br>
                  //Nils <br>
                </blockquote>
                <br>
              </blockquote>
              <br>
            </blockquote>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>