As Alan suggested I've created a new thread on hotspot-runtime-dev to discuss
the command line parsing issues.
On Jun 5, 2012, at 10:43 AM, Alan Bateman wrote:
> On 05/06/2012 15:29, Chris Dennis wrote:
>> 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
>>
> I would suggest moving the thread to hotspot-dev or hotspot-runtime-dev.
>
> On attempting to use -XX:MaxDirectMemorySize=5g on a 32-bit system then
> ideally this should be a fatal error, I don't think we would truncate the
> value to 32-bit. On specifying a value of -1 then I would suggest it should
> be consistent to other others, for example -XX:MaxHeapSize=-1 will fail with
> an unrecognized VM option error.
>
> -Alan.
>
>
