RFR(s): 8152176: Big ParGCCardsPerStrideChunk values can cause overflow for CMS GC (original) (raw)

Jon Masamitsu jon.masamitsu at oracle.com
Tue Mar 29 17:49:18 UTC 2016

Sangheon,

I agree that we don't want to expose CardTableModRefBS::_last_valid_index but I'd consider making CardTableModRefBS::cards_required() public. That would remove the need to duplicate the calculation and it seems a reasonable question to ask the card table implementation how many cards it is going to require. I'll let other disagree if they like.

Add in the message a little more about why the value is too large.

396 CommandLineError::print(verbose, 397 "ParGCCardsPerStrideChunk (" INTX_FORMAT ") "is too large for the heap size and " "must be " 398 "less than or equal to card table size (" SIZE_FORMAT ")\n", 399 value, card_table_size);

I think a little more information here would help future maintainers so instead of

403 // If n_strides which is used with ParGCCardsPerStrideChunk is really large, we would face an overflow.

This statement can overflow?

404 uintx n_strides = ParallelGCThreads * ParGCStridesPerThread;

Jon

On 3/28/2016 3:50 PM, sangheon wrote:

Hi all,

Could I have some reviews for this change? As very large value of ParGCCardsPerStrideChunk flag would result in an overflow, we need a constraint function after memory initialization. And the function will check the flag to be less than of equal to the size of card table and not to make an overflow with other stride factors(ParallelGCThreads and ParGCStridesPerThread). CR: https://bugs.openjdk.java.net/browse/JDK-8152176 Webrev: http://cr.openjdk.java.net/~sangheki/8152176/webrev.00 Testing: JPRT, all runtime/commandline JTREG tests on all platforms Thanks, Sangheon

-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160329/be6e65b2/attachment.htm>

More information about the hotspot-gc-dev mailing list