<!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>