<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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 class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~neliasso/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 class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~neliasso/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 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 class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~neliasso/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>
  </body>
</html>