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

[Leonid Mesnik]

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