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
