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

[Christoph Göttschkes]

On 2020-09-04 21:08, Chris Plummer wrote:
> +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.

I am only an author, so I can not commit into the repositories. I think 
this is also true for the submit repo? I never tried it.
I also don't know how the submit repo now works with skara. I think we 
are now supposed to use the /test command in the pull request [1]?

Regardless, I will create a PR for this issue, since I don't think we 
are now able to push the change without it.

Thanks,
Christoph

[1] 
https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/test

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