<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/23/2016 10:38 AM, Derek White
      wrote:<br>
    </div>
    <blockquote
      cite="mid:3679fdf5-8dee-0900-f8c2-f258e0aa6cd9@oracle.com"
      type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 5/22/16 10:01 PM, Jon Masamitsu
        wrote:<br>
      </div>
      <blockquote
        cite="mid:d573e400-f72a-3845-9209-a3d70b583572@oracle.com"
        type="cite"> <br>
        <br>
        On 5/20/2016 2:24 PM, Kim Barrett wrote: <br>
        <blockquote type="cite">Please review this fix for a serious
          performance bug in non-product <br>
          verification code in CMS precleaning. <br>
          <br>
          When precleaning an object, the mark bits for the object are
          verified, <br>
          including scanning for invalid set mark bits interior to the
          object. <br>
          If there are multiple dirty ranges applicable to the object, <br>
          processing each range leads to mark bit verification.  If the
          object <br>
          is large and there are many applicable dirty ranges, a lot of
          time may <br>
          be spent on this verification. <br>
          <br>
          For example, in a test that creates many large objArrays
          (O(64) of <br>
          O(16M) elements) and randomly scribbles on them, we've seen
          preclean <br>
          times of 20+ minutes because of this. <br>
            This verification isn't precise, since it is performed when
          the object <br>
          is visited during precleaning.  Not all live objects will
          require <br>
          precleaning, and this won't catch post-visit mark corruption. 
          This <br>
          verification is also redundant with that done later, during
          the sweep <br>
          phase, where it *is* precise.  So the only benefit of the
          problematic <br>
          verification is that it might catch a problem earlier. <br>
        </blockquote>
        <br>
        Instead of eliminate the verification can you leave it in for
        non-object arrays? <br>
        You might be able to do the verification for the object array
        once if you did it <br>
        only when an object header was in the dirty range but do it for
        the length of <br>
        the entire object array. <br>
        <br>
        If the verification were to consistently fail here and never
        fail when done during <br>
        the sweep, I think that bounds where in the code we need to look
        for a problem. <br>
        <br>
        Jon <br>
        <br>
      </blockquote>
      Alternatively, if we still wanted to verify this early (I have no
      strong opinion), could we simply verify the mark bits
      corresponding to the MemRegion passed in, instead of the entire
      object? Something like <br>
      <meta http-equiv="content-type" content="text/html;
        charset=windows-1252">
      <br>
      <meta http-equiv="content-type" content="text/html;
        charset=windows-1252">
      <pre>HeapWord* obj_rng_start = <span class="removed">addr+2</span>;</pre>
      <pre>HeapWord* obj_rng_end  = (<span class="removed">_bitMap->isMarked(addr+1)</span>) ? <span class="removed">addr+size-1</span> : <span class="removed">addr+size;</span></pre>
      <pre><span class="removed"></span><span class="removed">_bitMap->verifyNoOneBitsInRange(MAX2(</span><span class="removed">obj_rng_start, mr->start()), 
</span><span class="removed"><span class="removed">                                MIN2(</span><span class="removed">obj_rng_end, mr->end()));</span></span></pre>
    </blockquote>
    <br>
    This would be better than skipping the object arrays all together.<br>
    Not quite as thorough as the current checking but the excesses<br>
    of the current check are the problem (being thorough over and<br>
    over again).<br>
    <br>
    Jon<br>
    <br>
    <blockquote
      cite="mid:3679fdf5-8dee-0900-f8c2-f258e0aa6cd9@oracle.com"
      type="cite">
      <pre><span class="removed"><span class="removed">

</span></span></pre>
      <span class="removed"><span class="removed"> - Derek</span> </span><br>
      <span class="removed"></span><br>
      <br>
      <blockquote
        cite="mid:d573e400-f72a-3845-9209-a3d70b583572@oracle.com"
        type="cite">
        <blockquote type="cite"> <br>
          Since the problematic verification is redundant with later
          checks, we <br>
          simply remove it. <br>
          <br>
          CR: <br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="https://bugs.openjdk.java.net/browse/JDK-8156548">https://bugs.openjdk.java.net/browse/JDK-8156548</a>
          <br>
          <br>
          Webrev: <br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://cr.openjdk.java.net/%7Ekbarrett/8156548/webrev.00/">http://cr.openjdk.java.net/~kbarrett/8156548/webrev.00/</a>
          <br>
          <br>
          Testing: <br>
          Locally tested before and after change, using GC logging to
          see <br>
          precleaning time drop from 15+ minutes to 20 seconds. <br>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <p><br>
      </p>
    </blockquote>
    <br>
  </body>
</html>