RFR(XS): 8252773: [TESTBUG] serviceability/jvmti/GetObjectSizeOverflow fails due to OOM conditions
Chris Plummer
chris.plummer at oracle.com
Thu Sep 3 22:06:25 UTC 2020
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