JVM options: -client vs -server

Have you ever wonder what is this -client or -server switch when you run your java app? e.g.:

javaw.exe -client com.blogspot.sdoulger.LoopTest

that are also displayed in the Help of the java.exe e.g. where options include:

-client to select the “client” VM
-server to select the “server” VM

What’s the difference between the -client and -server systems?

These two systems are different binaries. They are essentially two different compilers (JITs) interfacing to the same runtime system. The client system is optimal for applications which need fast startup times or small footprints, the server system is optimal for applications where the overall performance is most important. In general the client system is better suited for interactive applications such as GUIs. Some of the other differences include the compilation policy,heap defaults, and inlining policy.

According to “The Java HotSpot Performance Engine Architecture“:

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.

The JDK contains both of the these systems in the distribution, so developers can choose which system they want by specifying -client or -server.

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.

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.

Note: It seems that the main cause of the difference in performance is the amount of optimizations.

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.

Both solutions deliver extremely reliable, secure, and maintainable environments to meet the demands of today’s enterprise customers.

Default options:

  • For Hotspot is client
  • For JRockit is server

JRockit’s client and server VM options
JRockit also has this two options with the default being server option (Hotspot is client).
JRockit client option is -client and server is -jrockit.

Hands-on example on the performance difference
An example taken from Onkar Joshi’s blog that proves the performance difference.

We run the following code with both switches:

package com.blogspot.sdoulger;

public class LoopTest {
    public LoopTest() {
        super();
    }

    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        spendTime();
        long end = System.currentTimeMillis();
        System.out.println("Time spent: "+ (end-start));
        
        LoopTest loopTest = new LoopTest();
    }

    private static void spendTime() {
        for (int i =500000000;i>0;i--) {
        }
    }
}

Note: The code is been compiled only once! The classes are the same in both runs!

With -client:
java.exe -client -classpath C:\JDeveloper\mywork\Test_java_client-server_switches\Project1\classes com.blogspot.sdoulger.LoopTest
Time spent: 766

With -server:
java.exe -server -classpath C:\JDeveloper\mywork\Test_java_client-server_switches\Project1\classes com.blogspot.sdoulger.LoopTest
Time spent: 0

It seems that the more aggressive optimazation of the server system, remove the loop as it understands that it does not perform any action!

Dig more/sources:

Reference: Difference between -client and -server JVM command line options from our JCG partner Spyros Doulgeridis at the Spyro’s Log blog.

Related Articles :
Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

One Response to "JVM options: -client vs -server"

  1. Spyros Doulgeridis says:

    I met a few actually :) OK. Most of them are medium level, but in the other hand it is not something like ABC that you learn in the University.

Leave a Reply


− 3 = six



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books