RFR(s): 8152188: Allow CMSBitMapYieldQuantum for BitMap::clear_range and clear_large_range
sangheon.kim at oracle.com
Fri Apr 1 20:53:01 UTC 2016
Thanks for the review.
On 04/01/2016 01:44 PM, Jon Masamitsu wrote:
> 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.
> The rest looks good.
> 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.
More information about the hotspot-gc-dev