RFR(XS): 8252773: [TESTBUG] serviceability/jvmti/GetObjectSizeOverflow fails due to OOM conditions
Christoph Göttschkes
christoph.goettschkes at microdoc.com
Mon Sep 7 06:57:52 UTC 2020
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
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
More information about the serviceability-dev
mailing list