RFR(XS): 8252773: [TESTBUG] serviceability/jvmti/GetObjectSizeOverflow fails due to OOM conditions
Leonid Mesnik
leonid.mesnik at oracle.com
Fri Sep 4 18:17:36 UTC 2020
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
>>>>
>>
>>
>>
>>
>
More information about the serviceability-dev
mailing list