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

[Srinivas Ramakrishna]

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

-- ramki


On Wed, Dec 21, 2011 at 12:53 AM, Tony Printezis
<tony.printezis at oracle.com>wrote:

>  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
> > wrote:
>
>> Hi all,
>>
>> Can I have a couple of code review for this small change?
>>
>> http://cr.openjdk.java.net/~tonyp/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/63f62b7e/attachment.htm>