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

[Filipp Zhinkin]

On 12/06/2014 02:42 AM, Jon Masamitsu wrote:
>
> 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.
OK, I see, thank you for explanation.

I've update tests to use MaxHeapSize instead of InitialHeapSize:

http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.01/

Thanks,
Filipp.
>
> Jon
>
>>
>> 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.
>>>
>>
>