[9] RFR(S): 8066143 [TESTBUG] : New tests in gc/survivorAlignment/ fails

Jon Masamitsu jon.masamitsu at oracle.com
Fri Dec 5 22:42:13 UTC 2014

On 12/5/2014 8:50 AM, Filipp Zhinkin wrote:
> Hi Jon,
> On 12/04/2014 10:41 PM, Jon Masamitsu wrote:
>> On 12/04/2014 08:40 AM, Filipp Zhinkin wrote:
>>> Hi all,
>>> please review the fix for 8066143.
>>> Issue:
>>> - newly developed tests on survivor alignment failed w/ client VM 
>>> and MaxRAMFraction=8;
>>> - test on the command line option fails w/ 
>>> +IgnoreUnrecognizedVMOptions.
>>> Root cause:
>>> - gc/survivorAlignment tests verifies that objects promoted to 
>>> survivor space
>>>   occupies some specific amount of space depending on 
>>> SurvivorAlignmentInBytes values.
>>>   To make sure that there will be enough space to fit all these 
>>> objects,
>>>   tests specify [Max]NewSize values. In some cases (like Client VM 
>>> and MaxRAMFraction=8)
>>>   initial heap sizecould be smaller then specified NewSize and it 
>>> will be resized,
>>>   thus survivor space usage in some cases may be less then expected,
>>>   just because its size is too small.
>>> - command line option test checks that SurvivorAlignmentInBytes is 
>>> experimental option
>>>   and expects that JVM startup willfail w/o 
>>> +UnlockExperimentalVMOptions specified
>>>   on the command line, but a set of command line options used in the 
>>> test may also
>>>   contain +IgnoreUnrecognizedVMOptions specified during a test run 
>>> and as a result
>>>   JVM startup won't fail.
>>> Proposed fix:
>>> - for all gc/survivirAlignment tests specify InitialHeapSize;
>> My first thought would have been to specify MaxHeapSize
>> rather than InitialHeapSize.  There will be a default max heap
>> size calculated for the platform and specifying InitialHeapSize
>> will affect the calculated max heap size but that could result
>> in an unexpectedly small old gen which might have unforeseen
>> consequences.
>> Was there a specific reason for choosing InitialHeapSize?
> Issue was caused by the fact that ergonomically chosen heap size
> could be smaller than MaxNewSize specified in tests, so I decided
> to limit lower bound for heap size by InitialHeapSize.

Sounds like the problem is that the ergonomics chooses a maximum
heap size that is too small and you should be setting MaxHeapSize
to be larger that MaxNewSize.  Setting InitialHeapSize will work because
choosing an InitialHeapSize smaller than the MaxHeapSize will cause
the MaxHeapSize to be increased but it is not obvious how much
it is increased.  It might be only a small amount leaving an old gen
that is too small.


> Thanks,
> Filipp.
>> Jon
>>> - update command line test to use @require tag in order to avoid 
>>> incompatible options.
>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066143
>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.00/
>>> Testing: manual & automated
>>> Best regards,
>>> Filipp.

More information about the hotspot-gc-dev mailing list