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

[John Cuthbertson]

Hi Tony,

This looks good to me.

JohnC

On 12/28/2011 2:38 AM, Tony Printezis wrote:
> 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/20120104/64f7c193/attachment.htm>