<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ramki,<br>
<br>
Thanks for looking at this! Here's an explanation why we need this:<br>
<br>
(As you know!) in G1 we don't have an initial-mark pause and we
piggy-back marking the roots on an evacuation pause. This means that
we might have to mark an object we are copying / have copied. This
is mostly straightforward and it's been in G1 for quite a while.<br>
<br>
John is working on some changes to piggy-back liveness counting on
the marking phase. For that we need to know the size of each object
we mark. For objects that are being moved this is not as
straightforward. Consider the case where a thread is scanning a root
that points to an object being copied by another thread. Even though
we know the reference to the from-/to-images we do not know whether
the to-image is actually complete given that an object gets
forwarded first, then copied and there's no easy way to find out
whether it's been copied or not without some additional
synchronization which it'd be good to avoid: we only need this
during initial-mark pauses which are infrequent.<br>
<br>
One idea is to always read the size from the from-image, which works
mots of the time apart from the case where the object is a chunked
object array since we use its length to store how much of the object
we have not processed yet (and without its length we cannot work out
its size). Again, currently there's no way to determine whether the
length is the actual length or an encoded index given that they both
look like ints >= 0. Encoding it as a negative integer, which is
what this changeset does, allows us to distinguish a valid length
(>=0) from an encoded index (<0).<br>
<br>
FWIW, here's the code (from a follow-up changeset) that relies on
this encoding to calculate the size of a forwarded object (old ->
from-image, obj -> to-image):<br>
<br>
<tt> int size;<br>
if (!old->is_objArray()) {<br>
// The easy case. This is safe, the from-image of all
non-object<br>
// arrays should be well formed.<br>
size = old->size();<br>
} else {<br>
objArrayOop array_old = objArrayOop(old);<br>
int length = array_old->length();<br>
if (length < 0) {<br>
// It's been chunked so we cannot trust the from-image. We
will<br>
// get the size from the to-image which we know is well
formed<br>
// (copy is finished before the length becomes negative).<br>
objArrayOop array_obj = objArrayOop(obj);<br>
length = array_obj->length();<br>
} else {<br>
// Because the length is positive we know it's correct, i.e.
the<br>
// array is not being chunked right now.<br>
}<br>
size = objArrayOopDesc::object_size(length);<br>
}</tt><br>
<br>
Hope this clears things up.<br>
<br>
Tony<br>
<br>
On 12/21/2011 01:34 AM, Srinivas Ramakrishna wrote:
<blockquote
cite="mid:CABzyjynyS2PMYOUsfotTXn2vaWvCmBYZo4d-P+k6t=Mp7A+YNA@mail.gmail.com"
type="cite">Hi Tony --<br>
<br>
For some reason, I cannot seem to be able to view either of the
CR's you mention below, and thus<br>
lack the requisite background context for this change. The
localized change however looks fine,<br>
and it is nice to distinguish the two states of the array in this
way by means of the sign of the length field.<br>
<br>
One question is whether, for the sake of debugging &
representational uniformity, it would make sense to use the same<br>
encoding in the other collectors that do this chunking (even
though I understand they may not have<br>
the need to deal with 6484965, whatever that might be :-)<br>
<br>
Reviewed!<br>
-- ramki<br>
<br>
<div class="gmail_quote">On Wed, Dec 14, 2011 at 2:17 PM, Tony
Printezis <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tony.printezis@oracle.com">tony.printezis@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Can I have a couple of code review for this small change?<br>
<br>
<a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Etonyp/7121623/webrev.0/"
target="_blank">http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/</a><br>
<br>
The CR has a bit more explanation. The short version is that
I'm now encoding the "start index of the next chunk" in the
from-space length field of a chunked array (say *that*
quickly!) as a negative value to always be able to distinguish
it from the real length. This will simplify the code for the
CR John is currently working on (6484965) but it's a small,
self-contained change so it's good to get it code reviewed and
pushed separately.<span class="HOEnZb"><font color="#888888"><br>
<br>
Tony<br>
<br>
</font></span></blockquote>
</div>
<br>
</blockquote>
</body>
</html>