From a customer point of view, not enough deatils are provided in javadoc regarding the behavior of different supported/non-supported options for 64bit VM.

The inhouse experts know the exact details on how the VM behaves with which option, all this info is not available in java doc.

Have attached an email thread which has the detailed dissscussion on this.

Example of info that is not available in doc (these are excerpts from the same attached email.) -->

Paul.H wrote :

We only support c2 (the server vm) on amd64.
Here's the effect of various switches.  On linux and windows,
the 32-bit and 64-bit vm's are in separate jre's and jdk's.
solaris-amd64 is the same as solaris-sparcv9: 32-bit and
64-bit vm's cohabit in the same jre/jdk.

Linux and Windows, 64-bit jre/jdk:
         -d32 produces an error
         -d64 invokes the 64-bit server vm
         -client silently invokes the 64-bit server vm
         -server invokes the 64-bit server vm
         -d64 -server invokes the 64-bit server vm
         no flags at all invokes the 64-bit server vm

Solaris: -d64 invokes the 64-bit server vm
         -client invokes the 32-bit client vm
         -server invokes the 32-bit server vm
         -d64 -server invokes the 64-bit server vm
         no flags at all invokes either the 32-bit client or
           32-bit server vm, according to server-class-machine
           ergonomics.
         -d32 invokes the 32-bit server vm, I think: not
           absolutely certain of this: it might instead
           do the same thing as no flags at all.
=======

Joe.D wrote --->

A few addendum to Paul's informative email,

On Solaris SPARC, "java -d32 foo" is the same as "java foo" if the java 
command is the 32-bit executable; i.e. if you don't go out of your way 
to invoke $JDK/bin/sparcv9/java instead of $JDK/bin/java; "$JDK/bin/java 
-d32" does not imply server.

Subsequent to the initial amd64 packaging discussions previously 
attached, it was decided to not have "java -client" be an error on 
64-bit platforms with server only; this is described in bug and ccc 
request 4942878 "Don't make "java -client" be an error on 64-bit 
platforms," http://ccc.sfbay/4942878.  However, my fix for his bug only 
changed the unix jvm.cfg files to alias client and server on 64-bit-only 
environments.

File a bug in java:tools and I can make the analogous changes for 64-bit 
windows platforms; the changes themselves are very simple, just updating 
one line in a platform-specific config file.

The online man pages for the java command discusses the ergonomics 
possibility:

http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html

>>Paul wrote
>>Scroll down for most of the info.  Note that Joe says in addition that
>>on Solaris, -d32 is the same as no switches at all.

It is a bit more subtle.  In a full 32/64-bit JDK install, there are two 
java executables, $JDK/bin/java and $JDK/bin/$64BITARCH/java (e.g. 
$JDK/bin/sparcv9/java).  Each of these java executables can exec the 
other if given the right flag:

$JDK/bin/java -d64 calls $JDK/bin/$64BITARCH/java
$JDK/bin/$64BITARCH/java -d32 calls $JDK/bin/java

Giving the executable of data model <n> a -d<n> flag is a no-op; in 
particular
$JDK/bin/java -d32
and
$JDK/bin/$64BITARCH/java -d64
are no-ops.

>>I didn't include the linux and windows 32-bit jre/jdk's switches.  

All the unix platforms now support -d32 and -d64, at least so far as 
they are recognized options and the using the no-op option won't result 
in an error.  The -d<n> options are not supported on windows.

>>Paul wrote
>>I believe they are or should be (Joe, pls correct me if I'm wrong)
>>
>> -d64 produces an error
>> -client invokes the 32-bit client vm
>> -server invokes the 32-bit server vm
>> -d32 -client invokes the 32-bit client vm
>> -d32 -server invokes the 32-bit server vm
>> no flags at all invokes either the 32-bit client or
>>   32-bit server vm, according to server-class-machine
>>   ergonomics.
>> -d32 is equivalent to no flags at all

On AMD64 linux (and IA64 linux), we natively only provide a 64-bit VM so 
-d32 is an error; in general -d<n> where <n> is the executable's data 
model is a no-op.

On unix, -client invokes the client vm or silently invokes the default 
vm if client is not present (i.e on 64-bit only platforms with server 
only) and -server invokes the server vm.  Adding a -d<n> option will try 
to run a vm with that data model; if such a vm is not present, you get 
an error.  On windows, on no platform do we provide a 32 and 64 bit 
combined JDK as a single unit; therefore, the -d<n> option is not 
supported.  While -client and -server will try to run those vms if 
available, IIRC, the windows JRE does not include the server vm.


>>server-class-machine ergo is covered someplace in the documentation,
>>but I forget where.
>>

It is described in Tigers' online Java manpage
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html

>>  I recall that it invokes the server vm if the
>>machine has at least 2 physical processors (e.g., 1 hyper-threaded
>>processor doesn't count) and 2gb of physical memory.
>>  

I believe that is the current definition.  There are also GC 
configuration aspects of the finding a server class machine.

-Joe










###@###.### 2005-03-02 02:37:08 GMT