Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6234731

Javadoc doesn't give enough details on 64bit VM behavior(sol/win/lin) for different options.



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


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

      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


      >>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
      $JDK/bin/java -d32
      $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

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


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


          Issue Links



              swamyv Swamy Venkataramanappa
              mdudhgaosunw Madhura Dudhgaonkar (Inactive)
              0 Vote for this issue
              2 Start watching this issue