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

[Christoph Göttschkes]

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