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

Derek White derek.white at oracle.com
Fri Mar 4 18:49:46 UTC 2016

Looks good!

On 3/4/16 10:22 AM, sangheon wrote:

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 'maxintx' which makes an overflow issue. I'm proposing to change to 'int' and limit its maximum to 'maxjint/3'. This flag is used when we want to process long object array into smaller pieces. The max array length is almost maxjint[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 'maxjint/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 'alignsizedown(maxjint - obj header size, MinObjAlignment)' [2]: Call System.gc() with VM option of '-XX:+{GC modes} -XX:MarkSweepAlwaysCompactCount=715827883' (=maxjint/3 + 1). Thanks, Sangheon

More information about the hotspot-gc-dev mailing list