CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array

[Tony Printezis]

Ramki,

Thanks for looking at this! Here's an explanation why we need this:

(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.

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.

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).

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):

   int size;
   if (!old->is_objArray()) {
     // The easy case. This is safe, the from-image of all non-object
     // arrays should be well formed.
     size = old->size();
   } else {
     objArrayOop array_old = objArrayOop(old);
     int length = array_old->length();
     if (length < 0) {
       // It's been chunked so we cannot trust the from-image. We will
       // get the size from the to-image which we know is well formed
       // (copy is finished before the length becomes negative).
       objArrayOop array_obj = objArrayOop(obj);
       length = array_obj->length();
     } else {
       // Because the length is positive we know it's correct, i.e. the
       // array is not being chunked right now.
     }
     size = objArrayOopDesc::object_size(length);
   }

Hope this clears things up.

Tony

On 12/21/2011 01:34 AM, Srinivas Ramakrishna wrote:
> Hi Tony --
>
> For some reason, I cannot seem to be able to view either of the CR's 
> you mention below, and thus
> lack the requisite background context for this change. The localized 
> change however looks fine,
> and it is nice to distinguish the two states of the array in this way 
> by means of the sign of the length field.
>
> One question is whether, for the sake of debugging & representational 
> uniformity, it would make sense to use the same
> encoding in the other collectors that do this chunking (even though I 
> understand they may not have
> the need to deal with 6484965, whatever that might be :-)
>
> Reviewed!
> -- ramki
>
> On Wed, Dec 14, 2011 at 2:17 PM, Tony Printezis 
> <tony.printezis at oracle.com <mailto:tony.printezis at oracle.com>> wrote:
>
>     Hi all,
>
>     Can I have a couple of code review for this small change?
>
>     http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/
>     <http://cr.openjdk.java.net/%7Etonyp/7121623/webrev.0/>
>
>     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.
>
>     Tony
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111221/99243378/attachment.htm>