RFR(xs): 8145192: 'count' variable can overflow in PSMarkSweep::invoke on 64 bit JVM
sangheon.kim at oracle.com
Sat Jan 23 00:02:18 UTC 2016
Thank you for reviewing this.
On 01/22/2016 12:52 PM, Tom Benson wrote:
> I think it would be *slightly* more logical to instead reduce
> MarkSweepAlwaysCompactCount to a uint, since there should be no need
> for it to be anywhere near even that large.
Okay, I will fix.
I considered change the flag to 'uint' as well but I selected this
approach as this is simpler. :)
> But I don't feel too strongly, and that would require changing the test.
I ran TestGCOld.java to trigger enough GCs and it was fine.
Let me post a new webrev after testing JPRT on Monday.
* I have one thing to note: JDK-8144578 is on review and its patch
contains to exclude testing this flag from TestOptionsWithRanges.java.
So if 8144578 is pushed earlier than this, I should revise this patch.
> So, the change looks OK to me.
> On 1/22/2016 2:56 PM, sangheon wrote:
>> Hi all,
>> Could I have reviews for this tiny change to avoid zero division?
>> 'uintx' type flag 'MarkSweepAlwaysCompactCount' is used to set 'uint'
>> type local variable and this would result in an overflow for big
>> As a solution, this local variable should be changed to 'uintx'.
>> I didn't add a new test as JDK-8144578 enables to check this problem.
>> CR: https://bugs.openjdk.java.net/browse/JDK-8145192
>> Webrev: http://cr.openjdk.java.net/~sangheki/8145192/webrev.00
>> Testing: JPRT, manual test
>> : Call System.gc() with VM option of '-XX:+UseParallelGC
>> -XX:-UseParallelOldGC -XX:MarkSweepAlwaysCompactCount=4294967296'
>> (=max_juint + 1).
More information about the hotspot-gc-dev