<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ramki,<br>
<br>
(sorry, I forgot to answer your question) We could implement the
same encoding on the other GCs but I'm not sure whether it's worth
it. Of course, if we had the encoding / decoding code factored out
we could have done it with no much effort. :-)<br>
<br>
Tony<br>
<br>
On 12/22/2011 01:31 AM, Srinivas Ramakrishna wrote:
<blockquote
cite="mid:CABzyjynsZ4iJ0kxOziRA6H57J_SYtvHdSOV6UDopaTOKfqJZVw@mail.gmail.com"
type="cite">Thanks Tony for the clear explanation of the context!.
So did you have any opinion about the second part of my email
below? (not that<br>
that issue needs to be done in this CR or anything, but just
thought it would be nice to have all scavengers use this
encoding.)<br>
<br>
-- ramki<br>
<br>
<br>
<div class="gmail_quote">On Wed, Dec 21, 2011 at 12:53 AM, 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">
<div 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.<span class="HOEnZb"><font
color="#888888"><br>
<br>
Tony</font></span>
<div>
<div class="h5"><br>
<br>
On 12/21/2011 01:34 AM, Srinivas Ramakrishna wrote:
<blockquote 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"
target="_blank">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><font color="#888888"><br>
<br>
Tony<br>
<br>
</font></span></blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>