<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks John.<br>
<br>
Any chance of getting one more review for this so that I can push
it? The marking changes rely on it.<br>
<br>
Thanks,<br>
<br>
Tony<br>
<br>
On 1/4/2012 2:20 PM, John Cuthbertson wrote:
<blockquote cite="mid:4F04A692.8090103@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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>
</blockquote>
</body>
</html>