7172708: 32/64 bit type issues on Windows

[Chris Dennis]

Alan,

The 5g issue is kind of complicated.  The current behavior of 32bit JVMs as I understand it is that the 5g will get narrowed down to a 32bit value by the printf used to propagate the value across from the launcher and in to the system properties of the spawned JVM.  Consider the result of running the following test class on a 32bit and 64bit VM:

public class TestMaxDirectMemory {

    public static void main(String[] args) {
	System.out.println(sun.misc.VM.maxDirectMemory());
    }
}

$ java -showversion -d32 -XX:MaxDirectMemorySize=5g TestMaxDirectMemory
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
Java HotSpot(TM) Client VM (build 20.6-b01-415, mixed mode)

1073741824

$ java -showversion -d64 -XX:MaxDirectMemorySize=5g TestMaxDirectMemory
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)

5368709120

This is why in the LimitDirectMemory.java source I added some logic based on sun.arch.data.model to perform the equivalent narrowing conversion internally.

It seems to me that we have a bunch of open and independent questions here:

1. What to do about the current MaxDirectMemorySize=-1 behavior.  Changing this might be a little tricky since -1 is currently used to propagate "unset" - causing the JDK code that consumes this value to use the default value.

2. What to do about the current error being thrown when trying to set MaxDirectMemorySize to an illegal value?
	$ ${JAVA_HOME_16}/bin/java -XX:MaxDirectMemorySize=foo
	Unrecognized VM option 'MaxDirectMemorySize=foo'
	Could not create the Java virtual machine.
	$ ${JAVA_HOME_17}/bin/java -XX:MaxDirectMemorySize=foo
	Error: Could not create the Java Virtual Machine.
	Error: A fatal exception has occurred. Program will exit.

3. Should we change the behavior for out of range values (e.g. 5G passed to a 32bit VM) passed to MaxDirectMemorySize?

Once these are decided there is also the question of what bug-id each of these can or should be fixed under.

Chris

On Jun 5, 2012, at 5:12 AM, Alan Bateman wrote:

> On 04/06/2012 14:38, Chris Dennis wrote:
>> :
>> 
>> The patch to increase test coverage to cover this issue is against the jdk sources, however the issue here is more complicated.  While modifying the LimitDirectMemory.sh jtreg test to cover this issue I've run in to some problems with the test - the code that is intended to test the parsing of 'illegal' values was broken.  I've 'fixed' this code in the patch to approximate the current behavior of the tip of the jdk7u-dev forest, but the test doesn't currently pass with these modifications (it fails for -XX:MaxDirectMemorySize=-1).  It's not clear to me to what extent the details of the behavior for these illegal values is important: is the text of the message important, is the current behavior with -1 a problem?  I'm also not sure whether these test changes should be part of a separate commit under a different bug-id?
>> 
>> As a further question (I seem to be full of questions today - sorry!) should the jdk changes go through the jdk8 forest first before being merged in to jdk7u-dev or are we okay to go in the other direction?
>> 
> Yes, the rule is that jdk changes should be in jdk8 first and then back-ported.
> 
> If you are adding coverage to this test then the important thing is that it be reliable on all platforms, including 32-bit. I see you've extended the test to run with -XX:MaxDirectMemorySize=5g but that isn't going to work on 32-bit. I would suggest that -XX:MaxDirectMemorySize=-1 be considered an error (I think that will be consistent with the error handling for other heap sizing options).
> 
> -Alan