+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.
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
