[13] RFR(xs) 8226462: [TESTBUG] runtime/appcds/sharedStrings/SysDictCrash.java failed with Cannot dump shared archive

[David Holmes]

Hi Calvin,

This seems okay, but I'm wondering whether we should use 
SkippedException in this case rather than passing without running the test?

Thanks,
David

On 25/06/2019 1:13 am, Calvin Cheung wrote:
> Hi David, Ioi,
> 
> Here's the latest webrev:
>      http://cr.openjdk.java.net/~ccheung/8226462/webrev.02/
> 
> I'll push the change after more testing.
> 
> thanks,
> Calvin
> 
> On 6/24/19, 7:19 PM, David Holmes wrote:
>> Hi Calvin,
>>
>> On 24/06/2019 7:10 pm, Calvin Cheung wrote:
>>> Hi David,
>>>
>>> On 6/24/19, 2:59 PM, David Holmes wrote:
>>>> Hi Calvin,
>>>>
>>>> On 23/06/2019 10:50 pm, Calvin Cheung wrote:
>>>>> Hi David,
>>>>>
>>>>> Thanks for your review!
>>>>>
>>>>> I've a different fix by issuing a warning message from the VM and 
>>>>> have the dump time part of the test to look for that warning 
>>>>> message in case there's a RuntimeException. If there's such 
>>>>> warning, don't continue further.
>>>>>
>>>>> Here's an updated webrev:
>>>>>      http://cr.openjdk.java.net/~ccheung/8226462/webrev.01/
>>>>>
>>>>> Warning message looks like the following:
>>>>>
>>>>> Java HotSpot(TM) 64-Bit Server VM warning: UseCompressedOops and 
>>>>> UseCompressedClassPointers have been disabled due to max heap 
>>>>> 33768409088 > compressed oop heap 32178700288
>>>>> Java HotSpot(TM) 64-Bit Server VM warning: Please check the setting 
>>>>> of MaxRAMPercentage 12.50
>>>>
>>>> If a warning is needed I think this should be a single warning, not 
>>>> two.
>>>>
>>>> But I'm concerned that this warning may be triggered unexpectedly in 
>>>> some of our test runs and that other tests won't be prepared for 
>>>> this warning to appear.
>>> How about changing it to a cds log statement?
>>>
>>> diff --git a/src/hotspot/share/runtime/arguments.cpp 
>>> b/src/hotspot/share/runtime/arguments.cpp
>>> --- a/src/hotspot/share/runtime/arguments.cpp
>>> +++ b/src/hotspot/share/runtime/arguments.cpp
>>> @@ -1815,6 +1815,10 @@
>>>         // was not specified.
>>>         if (reasonable_max > max_coop_heap) {
>>>           if (FLAG_IS_ERGO(UseCompressedOops) && override_coop_limit) {
>>> +          log_info(cds)("UseCompressedOops and 
>>> UseCompressedClassPointers have been disabled due to"
>>> +            " max heap " SIZE_FORMAT " > compressed oop heap " 
>>> SIZE_FORMAT ". "
>>> +            "Please check the setting of MaxRAMPercentage %5.2f."
>>> +            ,(size_t)reasonable_max, (size_t)max_coop_heap, 
>>> MaxRAMPercentage);
>>>             FLAG_SET_ERGO(UseCompressedOops, false);
>>>             FLAG_SET_ERGO(UseCompressedClassPointers, false);
>>>           } else {
>>>
>>> An example is:
>>> [0.002s][info][cds] UseCompressedOops and UseCompressedClassPointers 
>>> have been disabled due to max heap 43082346496 > compressed oop heap 
>>> 32178700288. Please check the setting of MaxRAMPercentage 70.00.
>>
>> Yes that seems better.
>>
>> Thanks,
>> David
>>> thanks,
>>> Calvin
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>> On 6/21/19, 6:00 PM, David Holmes wrote:
>>>>>> Hi Calvin,
>>>>>>
>>>>>> On 21/06/2019 3:16 pm, Calvin Cheung wrote:
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8226462
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8226462/webrev.00/
>>>>>>>
>>>>>>> On a test host with large amount of RAM, the UseCompressedOops 
>>>>>>> and the UseCompressedClassPointers flags would be disabled 
>>>>>>> ergonomically by the VM with the MaxRAMPercentage set to 12.5. To 
>>>>>>> void the test failure, the test has been changed to check the 
>>>>>>> given MaxRAMPercentage and uses it if the setting is <= 12.5.
>>>>>>
>>>>>> But if it fails on 12.5 presently then you would need to be < 12.5 
>>>>>> surely?
>>>>>>
>>>>>> And it's not the 12.5 per-se that is the issue IIUC but the amount 
>>>>>> of memory that 12.5% of RAM represents. If there is more memory 
>>>>>> you would need to use a smaller % to ensure it works - no?
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Ran the test 20 times on the linux test host where the failure 
>>>>>>> was reproduced.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Calvin