7172708: 32/64 bit type issues on Windows

[David Holmes]

This is being taken up on hotspot-runtime-dev, but I wanted to make a 
couple of responses to Alan ...

On 6/06/2012 12:43 AM, Alan Bateman wrote:
> 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

Presently hotspot does, simply because a 64-bit value is assigned to a 
32-bit variable. Other than that hotspot doesn't even look at the value 
of this flag. We would have to change that to sanity check its range.

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

A value of -1 means "use the default". The JDK side defines what that 
default is. Hotspots uses -1 a fair bit like this, when the actual 
default comes from outside the VM (eg OS defaults, or in this case 
something determined on the JDK side). We could instead not define the 
property at all as a way to say "use the default" - but that would then 
need a change on the JDK side and we would have issues with JDK version 
in that case. But it may be we can use -1 internally yet reject the user 
setting -1 directly.

Please follow up on hotspot-runtime-dev at openjdk.java.net.

David

> -Alan.
>
>