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

[Jon Masamitsu]

On 12/8/2014 4:59 AM, Filipp Zhinkin wrote:
> 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/

Changes look good.  Reviewed.

Jon

>
> 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.
>>>>
>>>
>>
>