Possible, by determining of disabled UseCompressedOops option and
forking vm again with required minimum heap value(-Xms).
Please review update: http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
Lev
On 03/17/2015 03:23 PM, David Holmes wrote:
So this is a problem that needs to be resolved. The memory
requirements of the test are platform dependent but can't be satisfied
on all platforms. Though I am surprised that 770M is needed given that
two incarnations ago we set -Xmx to 385M!
But it is appearing to be impossible to run this test in a way that
can work on all platforms.
David
On 17/03/2015 10:15 PM, Lev Priima wrote:
Yes.
Lev
On 03/17/2015 02:56 PM, David Holmes wrote:
On 17/03/2015 9:15 PM, Lev Priima wrote:
Hi David,
Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
MaxHeapSize down to -Xms(or even less down to default
InitialHeapSize in
case if -Xms also wasn't set explicitly). In other words explicit -Xmx
has priority over explicit MaxRAMFraction if both are set and
contradict
with each other.
Okay - that's good to know.
However the -Xmx770m is a problem - our small devices only have 512MB
of memory. Is the 770M only needed for 64-bit with -UseCompressedOops ?
Thanks,
David
Lev
On 03/17/2015 07:40 AM, David Holmes wrote:
Hi Lev,
On 17/03/2015 6:30 AM, Lev Priima wrote:
Please reviewand push:
Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
Tested locally:
jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
-XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
Test results: passed: 1
How does MaxRAMFraction interact with -Xmx?
Thanks,
David
Lev
