Difference between sdk and jre
Hello all
I don't know if this is the correct forum to post this question. But I didn't find a more apropiate forum to ask this question.
On one server I installed the sdk, on another server jre (both debian, downloaded ".bin"s from java.sun.com). Now if I do 'java -version' I get different outputs.
sdk: java -version
java version"1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
jre: java -version
java version"1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode)
Although these are the same java-Versions, the sdk has the option "sharing" and the jre doesn't. On the sdk-Server I only see one process if I run my application. On the server with jre there is a process for every running thread.
So, is this a configuration option, or is this compiled into the java-executables? Are there any performance disadvantages with the "non sharing"-Version?
Thanks for your answers.
Greetings.
Gerhard Siegesmund
[1248 byte] By [
Jerria] at [2007-10-2 23:21:58]
I'm guessing that the difference is in the machines you installed on. Starting with JDK-1.5.0, if you are running on a "server-class machine" (at least 2 CPUs and at least 2GB of memory), then the JVM chooses to run well for server-class applications. On less beefy machines it chooses to run well for client applications. I[m guessing that's the reason for the difference you see. You can, of course, choose to run either the client or server JVM by giving the "-client" or "-server" option on the command line.
The "sharing" in the version string refers to an improvement in startup time, which is currently only available in the client JVM. So the fact that it's not shown in the server version stamp is to be expected.
As far as the number of threads (linux processes): there should be approximately the same number regardless of the whether you are running the client or server JVM, and regardless of whether you are getting "sharing" or not. The JVM uses several threads internally, so they should all be visible. You can send a SIGQUIT to the JVM to have it dump a list of all the threads it is running.
> client applications. I[m guessing that's the reason for the difference you
> see. You can, of course, choose to run either the client or server JVM by
> giving the "-client" or "-server" option on the command line.
Great hint. Using java -server -version and accordingly java -client -version I
can "toggle" the sharing option. :)
> As far as the number of threads (linux processes): there should be
> approximately the same number regardless of the whether you are running the
> client or server JVM, and regardless of whether you are getting "sharing" or
> not. The JVM uses several threads internally, so they should all be visible.
> You can send a SIGQUIT to the JVM to have it dump a list of all the threads
> it is running.
Well. I see a distinct difference between two machines. On the one machine I
see only one process when I do "ps ax". On the other server I see a process for
every thread in the javavm. But: On both servers the application is started
with the same command options. I already had added the option -server to both
servers. So which option defines this behaviour? And is there a performance
advantage with either behaviour?
Thanks for your help!
Jerria at 2007-7-14 16:00:01 >
All other things being equal, the -client JVM with sharing will give you better startup times, but lower throughput overall, whereas the -server JVM will startup more slowly, but give you better throughput. We can't know what you want before you run your application, so we let you (make you :-) choose.
Hi,
This Discussion SO Far Has been enlightning to me.
I would like to know if passing the -native argumentto the java.exe
would make it use native threads instead of green threads implementation , and if yes , will it use multiple CPUs and to take it further is this the method used by App Server Vendors to limit the Liscencing on an app server , does Liscencing ( CPU Based) have some thing to do with the JVM arguments passed during the start up of the App Server ?
Also with reference to your discussion about getting a better through put by using the -server argument , I woul like to ask if it can be generalised as a practice that for applications that connect to other machines one should use -client and for aplications that allow other machines to connect to them , one should use -server (this might sound novie but i have never used these arguments earlier).
Regards
Ajay
All of the Java HotSpot virtual machines from Sun use only native threads. Green threads went out with JDK-1.2.2. If you are on a multi-processor box, your Java threads should run on as many processors as the operating system will allow. The -native command line option is accepted in the name of backward compatability, but is completely ignored by the current JVM's.
The use of "-client" or "-server" on the command line is not meant (directly) to mean that the JVM should be a "client" or a "server" in the sense of machines that communicate over a network. Rather those flags choose a set of runtime parameters that are appropriate for "client" (smaller, more interactive) or "server" (larger, more CPU intensive) applications. Most of the different in performance comes from the choice of runtime compiler: either a simpler but faster client compiler (for small interactive applications) or a full optimizing compiler (for more CPU intensive applications).
