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

[Tony Printezis]

Ramki,

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

Tony

On 12/22/2011 01:31 AM, Srinivas Ramakrishna wrote:
> 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 <mailto: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 <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/20111222/c4037cf5/attachment.htm>