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

[Jesper Wilhelmsson]

Ok, Looks good!
/Jesper

Den 4/3/16 kl. 16:22, skrev 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
>>>
>