On 6/30/2016 4:31 PM, Sergey Bylokhov wrote:
On 30.06.16 13:42, Semyon Sadetsky wrote:
Because it was not intentional behavior, such tests should not fill
the whole physical memory, especially so much memory.
Still unclear why "should not fill" when "it should" according to the
test spec...
It should fill the java heap, not the whole physical memory.
Don't see a contradiction here. If heap is limited to the physical RAM
then they are equivalent.
At least, please, add a caution comment to the Util.generateOOME() that
its usage should be accompanied by the -Xmx flag.
That helps to decrease probability to meet the same problem in the
future.
Webrev is updated:
http://cr.openjdk.java.net/~serb/8159899/webrev.01
The caution could be more noticeable. Thank you for adding it, though.
I'm ok with the fix.
--Semyon
This utility method is used in other tests which are not
covered by
the
fix but may fail due to the same reason.
Which one?
bug6795356.java
Covered by the fix.
TwentyThousandTest.java
already have -mx option.
WindowsLeak.java
already have -mx option.
To find them all you can search for Util.generateOOME() usages
good to know.
--Semyon
On 6/27/2016 6:25 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk9.
Some of our tests fails with timeout when they tries to generate
OOM.
This occur on the systems which have huge number of memory.
In the fix I added "-xm" option to minimize the available
amount of
memory.
Bug: https://bugs.openjdk.java.net/browse/JDK-8159899
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8159899/webrev.00
