Re: RFR(XXS) : 8190679 : java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

[David Holmes]

On 28/02/2018 7:17 AM, Igor Ignatyev wrote:

Hi David,

I have set Xmx equal to Xms, the test passes w/ different externally 
passed combinations of Xmx, Xms and UseCompressedOops.


http://cr.openjdk.java.net/~iignatyev//8190679/webrev.01/index.html


Looks good!

Thanks,
David


Thanks,
-- Igor

On Feb 26, 2018, at 9:00 PM, David Holmes > wrote:


Hi Igor,

On 27/02/2018 11:25 AM, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html

9 lines changed: 2 ins; 0 del; 7 mod;

Hi all,
could you please review the patch for TimSortStackSize2 test?
the test failed when externally passed (via -javaoption or -vmoption) 
-Xmx value is less than 770m or 385m, depending on UseCompressedOops. 
it happened because the test explicitly set Xms value, but didn't set 
Xmx.

now, the test sets Xmx as Xms times 2.


I'm not happy with setting Xmx at 2 times Xms - that seems to be 
setting ourselves up for another case where we can't set -Xmx at 
startup. This test has encountered problems in the past with external 
flag settings - see in particular the review thread for JDK-8075071:


http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032316.html

Will the test pass if we simply set -Xmx and -Xms to the same? Or 
(equivalently based on on previous review discussions) just set -Xmx 
instead of -Xms?


Thanks,
David

PS as it mostly affects hotspot testing, the patch will be pushed to 
jdk/hs.
webrev: 
http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
testing: java/util/Arrays/TimSortStackSize2.java  w/ and w/o 
externally provided Xmx value

JBS: https://bugs.openjdk.java.net/browse/JDK-8190679
Thanks,
-- Igor

Re: RFR(XXS) : 8190679 : java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

[Igor Ignatyev]

Hi David,

I have set Xmx equal to Xms, the test passes w/ different externally passed 
combinations of Xmx, Xms and UseCompressedOops.

http://cr.openjdk.java.net/~iignatyev//8190679/webrev.01/index.html 


Thanks,
-- Igor

> On Feb 26, 2018, at 9:00 PM, David Holmes  wrote:
> 
> Hi Igor,
> 
> On 27/02/2018 11:25 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
>>> 9 lines changed: 2 ins; 0 del; 7 mod;
>> Hi all,
>> could you please review the patch for TimSortStackSize2 test?
>> the test failed when externally passed (via -javaoption or -vmoption) -Xmx 
>> value is less than 770m or 385m, depending on UseCompressedOops. it happened 
>> because the test explicitly set Xms value, but didn't set Xmx.
>> now, the test sets Xmx as Xms times 2.
> 
> I'm not happy with setting Xmx at 2 times Xms - that seems to be setting 
> ourselves up for another case where we can't set -Xmx at startup. This test 
> has encountered problems in the past with external flag settings - see in 
> particular the review thread for JDK-8075071:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032316.html
> 
> Will the test pass if we simply set -Xmx and -Xms to the same? Or 
> (equivalently based on on previous review discussions) just set -Xmx instead 
> of -Xms?
> 
> Thanks,
> David
> 
>> PS as it mostly affects hotspot testing, the patch will be pushed to jdk/hs.
>> webrev: http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
>> testing: java/util/Arrays/TimSortStackSize2.java  w/ and w/o externally 
>> provided Xmx value
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8190679
>> Thanks,
>> -- Igor

Re: RFR(XXS) : 8190679 : java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

[David Holmes]

Hi Igor,

On 27/02/2018 11:25 AM, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html

9 lines changed: 2 ins; 0 del; 7 mod;


Hi all,

could you please review the patch for TimSortStackSize2 test?

the test failed when externally passed (via -javaoption or -vmoption) -Xmx 
value is less than 770m or 385m, depending on UseCompressedOops. it happened 
because the test explicitly set Xms value, but didn't set Xmx.
now, the test sets Xmx as Xms times 2.


I'm not happy with setting Xmx at 2 times Xms - that seems to be setting 
ourselves up for another case where we can't set -Xmx at startup. This 
test has encountered problems in the past with external flag settings - 
see in particular the review thread for JDK-8075071:


http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032316.html

Will the test pass if we simply set -Xmx and -Xms to the same? Or 
(equivalently based on on previous review discussions) just set -Xmx 
instead of -Xms?


Thanks,
David


PS as it mostly affects hotspot testing, the patch will be pushed to jdk/hs.

webrev: http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
testing: java/util/Arrays/TimSortStackSize2.java  w/ and w/o externally 
provided Xmx value
JBS: https://bugs.openjdk.java.net/browse/JDK-8190679

Thanks,
-- Igor

RFR(XXS) : 8190679 : java/util/Arrays/TimSortStackSize2.java fails with "Initial heap size set to a larger value than the maximum heap size"

[Igor Ignatyev]

http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
> 9 lines changed: 2 ins; 0 del; 7 mod; 

Hi all,

could you please review the patch for TimSortStackSize2 test?

the test failed when externally passed (via -javaoption or -vmoption) -Xmx 
value is less than 770m or 385m, depending on UseCompressedOops. it happened 
because the test explicitly set Xms value, but didn't set Xmx.
now, the test sets Xmx as Xms times 2.

PS as it mostly affects hotspot testing, the patch will be pushed to jdk/hs.

webrev: http://cr.openjdk.java.net/~iignatyev//8190679/webrev.00/index.html
testing: java/util/Arrays/TimSortStackSize2.java  w/ and w/o externally 
provided Xmx value
JBS: https://bugs.openjdk.java.net/browse/JDK-8190679

Thanks,
-- Igor