<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hi Tony,<br>
    <br>
    This looks good to me.<br>
    <br>
    JohnC<br>
    <br>
    On 12/28/2011 2:38 AM, Tony Printezis wrote:
    <blockquote cite="mid:4EFAF192.7080605@oracle.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Ramki,<br>
      <br>
      Quick follow-up on this. See below.<br>
      <br>
      On 12/27/2011 09:20 AM, Tony Printezis wrote:
      <blockquote cite="mid:4EF9D448.80305@oracle.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <br>
        <blockquote
cite="mid:CABzyjym_kek+WH9Cug=-W1YK2KBhw4iY5cKvHy3ZS+S923qgaA@mail.gmail.com"
          type="cite"> It is probably true that the post-image's length
          is not used<br>
          during GC once it's been copied, but it'd be good to check
          (I'm especially wary of CMS... but of course<br>
          this is limited to G1 -- does G1 ever need to scan or iterate
          over regions that are subject to being copied<br>
          into during an incremental pause?)<br>
        </blockquote>
        <br>
        This is of course something I was also worried about. In G1 we
        should not be scanning to-space objects that are being copied
        during GC, not only because the length might be incorrect due to
        this change but also because there are no guarantees that the
        objects are well formed (another thread might be in the process
        of copying them). For all regions we copy objects into we call
        save_marks() so that we never go over saved_mark() during
        scanning.<br>
        <br>
      </blockquote>
      <br>
      The above is correct. However your observation made me think of
      something related: we do of course scan the to-image of an object
      after we copy it to identify what it points to. When the object is
      chunked we use oop_iterate_range() to scan each chunk. I checked
      the definition of that method and it does not use the object's
      size / length when doing the scanning, it relies only on the start
      / end parameters passed to it. So, we're safe. :-) I updated the
      latest webrev I posted:<br>
      <br>
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://cr.openjdk.java.net/%7Etonyp/7121623/webrev.1/">http://cr.openjdk.java.net/~tonyp/7121623/webrev.1/</a><br>
      <br>
      to include the following comment:<br>
      <pre><span class="changed">4674   // Process indexes [start,end). It will also process the header</span>
<span class="changed">4675   // along with the first chunk (i.e., the chunk with start == 0).</span>
<span class="changed">4676   // Note that at this point the length field of to_obj_array is not</span>
<span class="changed">4677   // correct given that we are using it to keep track of the next</span>
<span class="changed">4678   // start index. oop_iterate_range() (thankfully!) ignores the length</span>
<span class="changed">4679   // field and only relies on the start / end parameters.  It does</span>
<span class="changed">4680   // however return the size of the object which will be incorrect. So</span>
<span class="changed">4681   // we have to ignore it even if we wanted to use it.</span>
<span class="changed">4682   to_obj_array->oop_iterate_range(&_scanner, start, end);</span></pre>
      <br>
      Tony<br>
      <br>
    </blockquote>
  </body>
</html>