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

sangheon sangheon.kim at oracle.com
Fri Mar 4 15:33:20 UTC 2016


Thanks Jesper!

Sangheon


On 03/04/2016 07:32 AM, Jesper Wilhelmsson wrote:
> 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
>>>>
>>




More information about the hotspot-gc-dev mailing list