RFR(s): 8145204: JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC is used

[sangheon]

Hi Jesper,

Thanks for looking at this.

The reason is that related routines that I described below use 'int' and 
as you know Java array length is also using 'int'.

Thanks,
Sangheon


On 03/04/2016 07:15 AM, Jesper Wilhelmsson wrote:
> Hi Sangheon,
>
> Why do you choose to change to int rather than uint? Seems to me this 
> flag should be unsigned.
>
> Thanks,
> /Jesper
>
>
> Den 4/3/16 kl. 16:08, skrev sangheon:
>> Hi all,
>>
>> Could I get a couple of reviews for this tiny change for 
>> ParGCArrayScanChunk flag?
>>
>> This flag is 'intx' and has a maximum range of 'max_intx' which makes an
>> overflow issue.
>> I'm proposing to change to 'int' and limit its maximum to 'max_jint/3'.
>>
>> This flag is used when we want to process long object array into 
>> smaller pieces.
>> The max array length is almost max_jint[1] and the decision for split 
>> is made
>> like below:
>>
>> int remainder = array length - ParGCArrayScanChunk;
>> if (remainder > 2 * ParGCArrayScanChunk) {
>>    // split to smaller pieces
>> }
>>
>> So larger than 'max_jint/3 (approximate)' would not be handled 
>> separately.
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8145204
>> Webrev: http://cr.openjdk.java.net/~sangheki/8145204/webrev.00
>> Testing: JPRT, manual test[2]
>>
>> [1]: our implementation is 'align_size_down(max_jint - obj header size,
>> MinObjAlignment)'
>> [2]: Call System.gc() with VM option of '-XX:+{GC modes}
>> -XX:MarkSweepAlwaysCompactCount=715827883' (=max_jint/3 + 1).
>>
>> Thanks,
>> Sangheon
>>