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
