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

[Calvin Cheung]

Hi David,

I pushed the change before your email. Let me know if I should file 
another bug to use the SkippedException.

thanks,
Calvin

On 6/27/19, 5:44 AM, David Holmes wrote:
> 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