-XX:MaxDirectMemorySize argument parsing
cdennis at terracottatech.com
Tue Jun 5 08:36:51 PDT 2012
This topic started life as a discussion around some test changes for 7172708. While working on modifying the LimitDirectMemory.sh test to cover the bug I discovered some deficiencies in the test that had allowed a few small regressions in code behavior. Starting a discussion brought up some more issues with the argument parsing. The original thread in jdk7u-dev contains the full context of this discussion (subject: "7172708: 32/64 bit type issues on Windows"). Alan Bateman suggested we move this discussion here, so I'm going to attempt to summarize the issues as they currently stand (I'm not including the faulty behavior caused by 7172708).
A: -XX:MaxDirectMemorySize=-1: This currently results in the JVM using the "default" value for MaxDirectMemorySize (Runtime.getRuntime().maxMemory()) since MaxDirectMemorySize uses "-1" as it's default value (and is consequently typed as intx and not uintx).
B: -XX:MaxDirectMemorySize=-?: Any other negative value results in the JVM using 64M as the value for MaxDirectMemorySize.
C: -XX:MaxDirectMemorySize=5g: On a 32-bit JVM this gets silently narrowed down to 1g.
D: -XX:MaxDirectMemorySize=foo: This causes the JVM to fail with:
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I'm in the process of fixing A, B and C, as I'm assuming the correct resolutions are pretty obvious: they should all be illegal values. Does anyone think fixing would cause problems (e.g. backwards compatibility related)?
I haven't looked at the root cause of D yet, but this message is printed for all illegal options passed to JVM (rather then the old "Unrecognized..." message) so D to me looks like a more global issue.
More information about the hotspot-runtime-dev