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

[Tony Printezis]

Ramki,

Quick follow-up on this. See below.

On 12/27/2011 09:20 AM, Tony Printezis wrote:
>
>> It is probably true that the post-image's length is not used
>> during GC once it's been copied, but it'd be good to check (I'm 
>> especially wary of CMS... but of course
>> this is limited to G1 -- does G1 ever need to scan or iterate over 
>> regions that are subject to being copied
>> into during an incremental pause?)
>
> This is of course something I was also worried about. In G1 we should 
> not be scanning to-space objects that are being copied during GC, not 
> only because the length might be incorrect due to this change but also 
> because there are no guarantees that the objects are well formed 
> (another thread might be in the process of copying them). For all 
> regions we copy objects into we call save_marks() so that we never go 
> over saved_mark() during scanning.
>

The above is correct. However your observation made me think of 
something related: we do of course scan the to-image of an object after 
we copy it to identify what it points to. When the object is chunked we 
use oop_iterate_range() to scan each chunk. I checked the definition of 
that method and it does not use the object's size / length when doing 
the scanning, it relies only on the start / end parameters passed to it. 
So, we're safe. :-) I updated the latest webrev I posted:

http://cr.openjdk.java.net/~tonyp/7121623/webrev.1/

to include the following comment:

4674   // Process indexes [start,end). It will also process the header
4675   // along with the first chunk (i.e., the chunk with start == 0).
4676   // Note that at this point the length field of to_obj_array is not
4677   // correct given that we are using it to keep track of the next
4678   // start index. oop_iterate_range() (thankfully!) ignores the length
4679   // field and only relies on the start / end parameters.  It does
4680   // however return the size of the object which will be incorrect. So
4681   // we have to ignore it even if we wanted to use it.
4682   to_obj_array->oop_iterate_range(&_scanner, start, end);


Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111228/fddc5e15/attachment.htm>