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

[Jesper Wilhelmsson]

Looks good!
/Jesper

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