RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM

Jon Masamitsu jon.masamitsu at oracle.com
Wed Dec 16 00:38:21 UTC 2015

On 12/15/2015 3:47 PM, sangheon wrote:
> Hi Jesper,
> Thanks for the review!
> Sangheon
> On 12/15/2015 03:33 PM, Jesper Wilhelmsson wrote:
>> Looks good!
>> /Jesper
>> Den 16/12/15 kl. 00:10, skrev sangheon:
>>> Hi all,
>>> Could I get some reviews for this change?
>>> Current 32bit binary with NUMAInterleavingGranularity=2g on server 
>>> mode fires an
>>> assert on Windows as we are proceeding without memory allocation 
>>> failure check
>>> at CodeCache::reserve_heap_memory.
>>> I think the constraint function can be removed with maximum range of 
>>> 2G/8192G.
>>> These are the maximum available memory on Windows and smaller values 
>>> can be used
>>> but I wanted to avoid adding artificial limit. With this limitation, 
>>> current
>>> constraint function for overflow check is not needed.
>>> And we need to check allocation failure.
>>> This issue is not reproducible with client mode as the different 
>>> default value
>>> of ReservedCodeCacheSize sets SegmentedCodeCache to false. And
>>> CodeCache::reserve_heap_memory() is called only when 
>>> SegmentedCodeCache is enabled.
>>> Skipped adding a test as TestOptionsWithRanges.java is enough when 
>>> this is
>>> combined with nightly vm option rotation.
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8144949
>>> Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00
>>> Testing: JPRT (with TestOptionsWithRanges.java enabled), manual 
>>> tests on Windows
>>> machine(to test several option combination).


Could you check if the changes in globals.hpp can be put in


Since this is a windows specific flag, it should work to
go in windows.hpp.

On 32bit upper limit is 2G.  Is that the largest value that can be used
without having to check for arithmetic overflow?

>>> Thanks,
>>> Sangheon

More information about the hotspot-gc-dev mailing list