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

[Tony Printezis]

Thanks John.

Any chance of getting one more review for this so that I can push it? 
The marking changes rely on it.

Thanks,

Tony

On 1/4/2012 2:20 PM, John Cuthbertson wrote:
> 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/6dbeb400/attachment.htm>