tags:

views:

9483

answers:

5

Is there any real practical difference between "java -server" and "java -client"? All I can find on Sun's site is a vague "-server starts slower but should run faster". What are the real differences? (Using JDK 1.6.0_07 currently.)

+1  A: 

I've not noticed any difference in startup time between the 2, but clocked a very minimal improvement in application performance with "-server" (Solaris server, everyone using SunRays to run the app). That was under 1.5.

Brian Knoblauch
Depends on what your program is doing. For some processor-intensive applications that do the same thing repeatedly, I have noticed *huge* (up to 10x) improvements with -server.
Dan Dyer
Dan, do you have a reference to this? I'd like to investigate further.
Thorbjørn Ravn Andersen
Running Sunflow with the server VM is MUCH faster than client. http://sunflow.sourceforge.net/
quadelirus
+5  A: 

IIRC the server VM does more hotspot optimizations at startup so it runs faster but takes a little longer to start and uses more memory. The client VM defers most of the optimization to allow faster startup.

Edit to add: Here's some info from Sun, it's not very specific but will give you some ideas.

Mike Akers
+1  A: 

IIRC, it involves garbage collection strategies. The theory is that a client and server will be different in terms of short-lived objects, which is important for modern GC algorithms.

Here is a link on server mode. Alas, they don't mention client mode.

Here is a very thorough link on GC in general; this is a more basic article. Not sure if either address -server vs -client but this is relevant material.

At No Fluff Just Stuff, both Ken Sipe and Glenn Vandenburg do great talks on this kind of thing.

Michael Easter
+23  A: 

This is really linked to HotSpot and the default option values which differ between client and server configuration

From the whitepaper:

The JDK includes two flavors of the VM -- a client-side offering, and a VM tuned for server applications. These two solutions share the Java HotSpot runtime environment code base, but use different compilers that are suited to the distinctly unique performance characteristics of clients and servers. These differences include the compilation inlining policy and heap defaults.

Although the Server and the Client VMs are similar, the Server VM has been specially tuned to maximize peak operating speed. It is intended for executing long-running server applications, which need the fastest possible operating speed more than a fast start-up time or smaller runtime memory footprint.

The Client VM compiler serves as an upgrade for both the Classic VM and the just-in-time (JIT) compilers used by previous versions of the JDK. The Client VM offers improved run time performance for applications and applets. The Java HotSpot Client VM has been specially tuned to reduce application start-up time and memory footprint, making it particularly well suited for client environments. In general, the client system is better for GUIs.

So the real difference is also on the compiler level:

The Client VM compiler does not try to execute many of the more complex optimizations performed by the compiler in the Server VM, but in exchange, it requires less time to analyze and compile a piece of code. This means the Client VM can start up faster and requires a smaller memory footprint.

The Server VM contains an advanced adaptive compiler that supports many of the same types of optimizations performed by optimizing C++ compilers, as well as some optimizations that cannot be done by traditional compilers, such as aggressive inlining across virtual method invocations. This is a competitive and performance advantage over static compilers. Adaptive optimization technology is very flexible in its approach, and typically outperforms even advanced static analysis and compilation techniques.

Note: the upcoming release of jdk6 update 10 will also propose a faster startup time, but for a different reason than the hotspot options: it will be packaged differently, with a much smaller kernel.

VonC
jdk6 update 10 and onwards have a background process keeping the runtime libraries in memory allowing for much faster startup for new processes than having to page it all in on demand.
Thorbjørn Ravn Andersen
Thought the client vm also inlined aggressively, oh well.
Thorbjørn Ravn Andersen
A: 

One difference I've just noticed is that in "client" mode, it seems the JVM actually gives some unused memory back to the operating system - whereas with "server" mode, once the JVM grabs the memory, it won't give it back. Thats how it appears on Solaris with Java6 anyway (using prstat -Z to see the amount of memory allocated to a process).

prule