RFR(s): 8152188: Allow CMSBitMapYieldQuantum for BitMap::clear_range and clear_large_range

sangheon sangheon.kim at oracle.com
Fri Apr 1 20:53:01 UTC 2016


Hi Jon,

Thanks for the review.

On 04/01/2016 01:44 PM, Jon Masamitsu wrote:
> http://cr.openjdk.java.net/~sangheki/8152188/webrev.00/src/share/vm/runtime/commandLineFlagConstraintsGC.cpp.udiff.html 
>
>
> I would expand the message so that the user understands that the
> size depends on the heap size.
>
> + CommandLineError::print(verbose,
> + "CMSBitMapYieldQuantum (" SIZE_FORMAT ") must "
> + "be less than or equal to bitmap size (" SIZE_FORMAT ") " whose size 
> corresponds to the size of old generation of the Java heap\n",
> + value, bitmap_size);
I like this suggestion and applied.

Webrev:
http://cr.openjdk.java.net/~sangheki/8152188/webrev.01/
http://cr.openjdk.java.net/~sangheki/8152188/webrev.01_to_00

Thanks,
Sangheon


>
>
> The rest looks good.
>
> Jon
>
> On 3/31/2016 4:37 PM, sangheon wrote:
>> Hi all,
>>
>> Could I have a couple of reviews for this change?
>>
>> CMSBitMapYieldQuantum can be changed by command-line and different 
>> values on this flag result in different ranges at BitMap when we 
>> clear the bitmap by BitMap::clear_large_range(). And if we can't 
>> satisfy the criteria for 'large' range of '32', we will face an 
>> assert from BitMap::clear_large_range().
>> As we already have clear_range(), it would be better to call it 
>> instead of firing an assert.
>> If we change to use 'clear_range()' will resolve the problem as well, 
>> but I didn't want to change like that which would result in 
>> performance regression.
>> In addition, we need a constraint to limit its maximum not to exceed 
>> the mark bitmap size.
>>
>> CR: https://bugs.openjdk.java.net/browse/JDK-8152188
>> Webrev: http://cr.openjdk.java.net/~sangheki/8152188/webrev.00
>> Testing: JPRT, runtime/commandline JTREG tests for all platforms.
>>
>> Thanks,
>> Sangheon
>>
>



More information about the hotspot-gc-dev mailing list