Hi Lev,
On 24/03/2015 3:03 PM, Lev Priima wrote:
Hi David,
Please review and push update:
http://cr.openjdk.java.net/~lpriima/8075071/2/webrev/ .
NPE in WB happens when vm does not have requested flag. To make test run
on 32bit vm, where is no UseCompressedOops flag, I've added additional
null check in UseCompressedOops flag request:
62 Boolean compessedOops = WhiteBox.getWhiteBox()
63 .getBooleanVMFlag("UseCompressedOops");
64 final String xmsValue = "-Xms" +
65 ((compessedOops == null || compessedOops) ? "385" : "770")
66 + "m";
And if it's null then we are on 32bit vm, don't have big oops and can
run test with 385m at least.
I fixed the typo (compessedOops -> compressedOops), tested and pushed.
Thanks,
David
----
Lev
On 03/18/2015 03:25 PM, David Holmes wrote:
On 18/03/2015 9:46 PM, Lev Priima wrote:
On 03/18/2015 01:52 PM, David Holmes wrote:
On 18/03/2015 6:12 PM, Lev Priima wrote:
On 03/18/2015 04:46 AM, David Holmes wrote:
Hi Lev,
On 18/03/2015 9:07 AM, Lev Priima wrote:
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/
Yes that is the approach that is needed. But didn't you need to set
Xmx not Xms to deal with the MaxRAMFraction problem?
No. As I wrote before "-Xms" has priority over MaxRAMFraction:
No what you wrote before was that -Xmx has priority. Your original
patch set -Xmx in addition to the existing -Xms:
! * @run main/othervm -Xms385m -Xmx770m TimSortStackSize2 67108864
Yes this fix will also work. Both -Xms -Xmx have priority over
MaxRAMFraction. MaxRAMFraction can't shrink MaxHeapSize less than either
-Xms or -Xmx.
Let me see if I have this straight. With -Xms385M ergonomics will
select a maximum heap size, and that size is adequate to run the test
without additional flags. However if MaxRAMFraction is specified then
that maximum heap size gets reduced and the test then fails on 64-bit
when compressed oops are disabled. The original version of the fix set
-Xmx770M in addition to -Xms385M and that stops the affect of
MaxRAMFraction, and so the test passes (but seemingly using G1 can
change that?). Alternatively we can just set -Xms770M, but that won't
work for systems with less memory, so the current fix simply selects
the -Xms value based on whether or not we're using compressed oops,
and launches a new VM using that value.
Okay got it.
Explicit value of -Xmx770m with program which actually required and
allocate less memory(385m) is not a problem on machine with 512m until
we don't switch -XX:+UseG1GC.
That's why I had have agreed with declining this fix .
I originally said the -Xmx770 would be a problem for a machine with
512MB, but as you note it won't be a problem unless > 512MB is
actually needed - in which case there is nothing we can do. So my
objection was unfounded - sorry for the confusion on that.
New fix will work with either -Xms or -Xms in this line:
! final String xmsValue = "-Xms" + (WhiteBox.getWhiteBox()
-Xms makes tests more robust if jdk footprint will increase a little.
-Xmx will be better if we also want to catch possible jdk footprint
regression by this test.
Okay. As long as it works on all platforms with all options. :)
Thanks,
David
Lev
David
-----
MaxRAMFraction can't shrink MaxHeapSize less than specified by -Xms:
java -Xms385m -XX:+PrintFlagsFinal
-XX:MaxRAMFraction=9223372036854775807 -version | grep MaxHeapSize
uintx MaxHeapSize :=
404750336 {product}
java -Xms770m -XX:+PrintFlagsFinal
-XX:MaxRAMFraction=9223372036854775807 -version | grep MaxHeapSize
uintx MaxHeapSize :=
807403520 {product}
Thanks,
David
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
