-XX:MaxDirectMemorySize argument parsing

[David Holmes]

Hi Chris,

On 6/06/2012 1:36 AM, Chris Dennis wrote:
> 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).

Correct. -1 is used to indicate "use default". The default is handled on 
the JDK side - in sun.misc.VM. There has to be some value for the flag 
that means "use the default". So I don't see this changing.

> B: -XX:MaxDirectMemorySize=-?: Any other negative value results in the JVM using 64M as the value for MaxDirectMemorySize.

Again this is the behaviour of sun.misc.VM. It sets a default of 64M and 
only updates it if the MaxDirectMemorySize is not -1 but is > 0

> C: -XX:MaxDirectMemorySize=5g: On a 32-bit JVM this gets silently narrowed down to 1g.

What you are seeing here is a simple truncation from 64-bit to 32-bit, 
resulting in the following:

1G = 1073741824
2G = -2147483648
3G = -1073741824
4G = 0
5G = 1073741824

The type of the flag is limiting its max value < 2048MB

> 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.

If you give the wrong type of value to an option it is treated as an 
unknown option. You should see:
Unrecognized VM option 'MaxDirectMemorySize=foo'

though that may depend on the VM version (7+ ?)

> 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)?

Seems to me that if this flag needs to be used to pass very large values 
then it needs to be made a 64-bit "long".

We should also sanity check the value ( -1 || >0) and check it is <= 
Integer.MAX_VALUE. Right now hotspot doesn't look at this flag, it just 
sets its numeric value and uses that to set the property used on the JDK 
side.

David
-----

> 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.
>
> Chris