RFR(XS): 8252773: [TESTBUG] serviceability/jvmti/GetObjectSizeOverflow fails due to OOM conditions

[Chris Plummer]

+1 for webrev.02

Yes, this does remove the test from tier1 testing, but I think that is 
fine for any resourcehogs test. Have you run this through the submit 
repo? If so I can use your job to make sure it passes on all our platforms.

thanks,

Chris

On 9/4/20 11:17 AM, Leonid Mesnik wrote:
> Hi
>
> Thanks for fixing this. I prefer webrev.02. It doesn't needed to skip 
> OOME if we provide enough memory. Also, it complies with other 
> resourcehogs test. Please get 'R'eview and response from Chris.
>
> Leonid
>
> On 9/4/20 1:16 AM, Christoph Göttschkes wrote:
>> Hi,
>>
>> thanks for your feedback.
>> So for me, all options work. The @requries tag makes the test to be 
>> not selected. My solution also works (for me) since we don't run 
>> tests concurrently on our smaller devices, since most devices have 
>> issues with that. Probably because there are more tests which cause 
>> problems like this one.
>>
>> Since the test was in the tier1 group before, and I am not so 
>> familiar with the jvmti implementation/tests, I don't want to judge 
>> if moving is an option and simply trust you.
>>
>> I made a new webrev, which basically combines all 3 solutions into one:
>> https://cr.openjdk.java.net/~cgo/8252773/webrev.01
>>
>> I also made a second one, which moves the test, adds the @requires 
>> tag, but completely removes the checks for OOM conditions, since I 
>> guess the tests in resourcehogs should fail if there are not enough 
>> resources available?
>> https://cr.openjdk.java.net/~cgo/8252773/webrev.02
>>
>> Do you think the webrev.02 makes sense, or should we go with webrev.01.
>>
>> -- Christoph
>>
>> On 2020-09-04 00:06, Chris Plummer wrote:
>>> Hi Christoph,
>>>
>>> I think this test should be moved to 
>>> test/hotspot/jtreg/resourcehogs/serviceability/jvmti even if 
>>> @requires os.maxMemory fixes the issue. It's could actually already 
>>> be causing sporadic undiagnosed intermittent failures with other 
>>> tests being run concurrently. It's best to just get it moved and not 
>>> have it worry about ever causing problems by running concurrently 
>>> with other tests.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 9/3/20 1:37 PM, Leonid Mesnik wrote:
>>>>
>>>> Hi
>>>>
>>>> The exhausting of RAM could lead to unexpected failures of other 
>>>> tests executed concurrently on this host and/or other environment 
>>>> related issues. I think you might want to add *@requires* tag to 
>>>> skip test on the hosts with small amount of RAM. Like '@requires 
>>>> os.maxMemory > 6G'.
>>>>
>>>> See for detailed info: 
>>>> https://openjdk.java.net/jtreg/tag-spec.html#requires_names
>>>>
>>>> For real memory and cpu consumers we have separate directory 
>>>> 'resourcehogs/serviceability' where tests are not executed 
>>>> non-concurrently. However these tests should be executed separately 
>>>> and I think you need to move 
>>>> serviceability/jvmti/GetObjectSizeOverflow there only you still see 
>>>> any problems after adding @requires tag.
>>>>
>>>> Leonid
>>>>
>>>> On 9/3/20 8:25 AM, Christoph Göttschkes wrote:
>>>>> Hi,
>>>>>
>>>>> please review the following patch for the GetObjectSizeOverflow test.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252773
>>>>> Webrev: https://cr.openjdk.java.net/~cgo/8252773/webrev.00
>>>>>
>>>>> The test case already handles out of memory conditions, but not if 
>>>>> the whole JVM crashes because of it.
>>>>>
>>>>> Thanks,
>>>>> Christoph
>>>>>
>>>
>>>
>>>
>>>
>>