Real differences between java -server and java -client

Question

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

User · Answer

From Goetz - Java Concurrency in Practice:

Debugging tip: For server applications, be sure to always specify the -server JVM command line switch when invoking the JVM, even for development and testing. The server JVM performs more optimization than the client JVM, such as hoisting variables out of a loop that are not modified in the loop; code that might appear to work in the development environment (client JVM) can break in the deployment environment (server JVM). For example, had we “forgotten” to declare the variable asleep as volatile in Listing 3.4, the server JVM could hoist the test out of the loop (turning it into an infinite loop), but the client JVM would not. An infinite loop that shows up in development is far less costly than one that only shows up in production.

Listing 3.4. Counting sheep.

volatile boolean asleep; ... while (!asleep) countSomeSheep();

My emphasis. YMMV

User · Answer

This is really linked to HotSpot and the default option values  Java HotSpot VM Options  which differ between client and server configuration  From Chapter 2 of the whitepaper  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  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 release of jdk6 update 10  see Update Release Notes Changes in 1 6 0 10  tried to improve startup time  but for a different reason than the hotspot options  being packaged differently with a much smaller kernel   G  Demecki points out in the comments that in 64-bit versions of JDK  the -client option is ignored for many years  See Windows java command  -client   Selects the Java HotSpot Client VM  A 64-bit capable JDK currently ignores this option and instead uses the Java Hotspot Server VM

User · Answer

Oracle   s online documentation provides some information for Java SE 7   On the java     the Java application launcher page for Windows  the -client option is ignored in a 64-bit JDK      Select the Java HotSpot Client VM  A 64-bit capable jdk currently ignores this option and instead uses the Java HotSpot Server VM     However  to make things interesting   under -server it states      Select the Java HotSpot Server VM  On a 64-bit capable jdk only the Java HotSpot Server VM is supported so the -server option is implicit  This is subject to change in a future release     The Server-Class Machine Detection page gives information on which VM is selected by OS and architecture   I don   t know how much of this applies to JDK 6

User · Answer

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

User · Answer

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

User · Answer

Last time I had a look at this   and admittedly it was a while back  the biggest difference I noticed was in the garbage collection    IIRC    The server heap VM has a differnt number of generations than the Client VM  and a different garbage collection algorithm  This may not be true anymore The server VM will allocate memory and not release it to the OS The server VM will use more sophisticated optimisation algorithms  and hence have bigger time and memory requirements for optimisation   If you can compare two java VMs  one client  one server using the jvisualvm tool  you should see a difference in the frequency and effect of the garbage collection  as well as in the number of generations    I had a pair of screenshots that showed the difference really well  but I can t reproduce as I have a 64 bit JVM which only implements the server VM   And I can t be bothered to download and wrangle the 32 bit version on my system as well    This doesn t seem to be the case anymore  having tried running some code on windows with both server and client VMs  I seem to get the same generation model for both

User · Answer

This is really linked to HotSpot and the default option values  Java HotSpot VM Options  which differ between client and server configuration  From Chapter 2 of the whitepaper  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  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 release of jdk6 update 10  see Update Release Notes Changes in 1 6 0 10  tried to improve startup time  but for a different reason than the hotspot options  being packaged differently with a much smaller kernel   G  Demecki points out in the comments that in 64-bit versions of JDK  the -client option is ignored for many years  See Windows java command  -client   Selects the Java HotSpot Client VM  A 64-bit capable JDK currently ignores this option and instead uses the Java Hotspot Server VM

User · Answer

The most visible immediate difference in older versions of Java would be the memory allocated to a -client as opposed to a -server application  For instance  on my Linux system  I get     java -XX  PrintFlagsFinal -version 2 gt  amp 1   grep -i -E  heapsize permsize version  uintx AdaptivePermSizeWeight                 20                product  uintx ErgoHeapSizeLimit                      0                 product  uintx InitialHeapSize                        66328448          product  uintx LargePageHeapSizeThreshold             134217728         product  uintx MaxHeapSize                            1063256064        product  uintx MaxPermSize                            67108864          pd product  uintx PermSize                               16777216          pd product  java version  1 6 0 24    as it defaults to -server  but with the -client option I get     java -client -XX  PrintFlagsFinal -version 2 gt  amp 1   grep -i -E  heapsize permsize version  uintx AdaptivePermSizeWeight                 20                product  uintx ErgoHeapSizeLimit                      0                 product  uintx InitialHeapSize                        16777216          product  uintx LargePageHeapSizeThreshold             134217728         product  uintx MaxHeapSize                            268435456         product  uintx MaxPermSize                            67108864          pd product  uintx PermSize                               12582912          pd product  java version  1 6 0 24    so with -server most of the memory limits and initial allocations are much higher for this java version   These values can change for different combinations of architecture  operating system and jvm version however  Recent versions of the jvm have removed flags and re-moved many of the distinctions between server and client   Remember too that you can see all the details of a running jvm using jvisualvm  This is useful if you have users who or modules which set JAVA OPTS or use scripts which change command line options  This will also let you monitor  in real time  heap and permgen space usage along with lots of other stats

User · Answer

This is really linked to HotSpot and the default option values  Java HotSpot VM Options  which differ between client and server configuration  From Chapter 2 of the whitepaper  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  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 release of jdk6 update 10  see Update Release Notes Changes in 1 6 0 10  tried to improve startup time  but for a different reason than the hotspot options  being packaged differently with a much smaller kernel   G  Demecki points out in the comments that in 64-bit versions of JDK  the -client option is ignored for many years  See Windows java command  -client   Selects the Java HotSpot Client VM  A 64-bit capable JDK currently ignores this option and instead uses the Java Hotspot Server VM

User · Answer

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

User · Answer

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

User · Answer

the -client and -server 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      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 gt 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  mywork classes com blogspot sdoulger LoopTest  Time spent  766    With -server   java exe -server -classpath C  mywork 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   Reference

User · Answer

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

User · Answer

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

User · Answer

Last time I had a look at this   and admittedly it was a while back  the biggest difference I noticed was in the garbage collection    IIRC    The server heap VM has a differnt number of generations than the Client VM  and a different garbage collection algorithm  This may not be true anymore The server VM will allocate memory and not release it to the OS The server VM will use more sophisticated optimisation algorithms  and hence have bigger time and memory requirements for optimisation   If you can compare two java VMs  one client  one server using the jvisualvm tool  you should see a difference in the frequency and effect of the garbage collection  as well as in the number of generations    I had a pair of screenshots that showed the difference really well  but I can t reproduce as I have a 64 bit JVM which only implements the server VM   And I can t be bothered to download and wrangle the 32 bit version on my system as well    This doesn t seem to be the case anymore  having tried running some code on windows with both server and client VMs  I seem to get the same generation model for both

User · Answer

When doing a migration from 1 4 to 1 7  1 7 0 55   version The thing that we observed here is  there is no such differences in default values assigned to heapsize permsize ThreadStackSize parameters in client  amp  server mode    By the way   http   www oracle com technetwork java ergo5-140223 html   This is the snippet taken from above link   initial heap size of 1 64 of physical memory up to 1Gbyte maximum heap size of    of physical memory up to 1Gbyte   ThreadStackSize is higher in 1 7  while going through Open JDK forum there are discussions which stated frame size is somewhat higher in 1 7 version  It is believed real difference could be possible to measure at run time based on your behavior of your application

User · Answer

When doing a migration from 1 4 to 1 7  1 7 0 55   version The thing that we observed here is  there is no such differences in default values assigned to heapsize permsize ThreadStackSize parameters in client  amp  server mode    By the way   http   www oracle com technetwork java ergo5-140223 html   This is the snippet taken from above link   initial heap size of 1 64 of physical memory up to 1Gbyte maximum heap size of    of physical memory up to 1Gbyte   ThreadStackSize is higher in 1 7  while going through Open JDK forum there are discussions which stated frame size is somewhat higher in 1 7 version  It is believed real difference could be possible to measure at run time based on your behavior of your application

User · Answer

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

User · Answer

The most visible immediate difference in older versions of Java would be the memory allocated to a -client as opposed to a -server application  For instance  on my Linux system  I get     java -XX  PrintFlagsFinal -version 2 gt  amp 1   grep -i -E  heapsize permsize version  uintx AdaptivePermSizeWeight                 20                product  uintx ErgoHeapSizeLimit                      0                 product  uintx InitialHeapSize                        66328448          product  uintx LargePageHeapSizeThreshold             134217728         product  uintx MaxHeapSize                            1063256064        product  uintx MaxPermSize                            67108864          pd product  uintx PermSize                               16777216          pd product  java version  1 6 0 24    as it defaults to -server  but with the -client option I get     java -client -XX  PrintFlagsFinal -version 2 gt  amp 1   grep -i -E  heapsize permsize version  uintx AdaptivePermSizeWeight                 20                product  uintx ErgoHeapSizeLimit                      0                 product  uintx InitialHeapSize                        16777216          product  uintx LargePageHeapSizeThreshold             134217728         product  uintx MaxHeapSize                            268435456         product  uintx MaxPermSize                            67108864          pd product  uintx PermSize                               12582912          pd product  java version  1 6 0 24    so with -server most of the memory limits and initial allocations are much higher for this java version   These values can change for different combinations of architecture  operating system and jvm version however  Recent versions of the jvm have removed flags and re-moved many of the distinctions between server and client   Remember too that you can see all the details of a running jvm using jvisualvm  This is useful if you have users who or modules which set JAVA OPTS or use scripts which change command line options  This will also let you monitor  in real time  heap and permgen space usage along with lots of other stats

User · Answer

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

User · Answer

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

User · Answer

Oracle   s online documentation provides some information for Java SE 7   On the java     the Java application launcher page for Windows  the -client option is ignored in a 64-bit JDK      Select the Java HotSpot Client VM  A 64-bit capable jdk currently ignores this option and instead uses the Java HotSpot Server VM     However  to make things interesting   under -server it states      Select the Java HotSpot Server VM  On a 64-bit capable jdk only the Java HotSpot Server VM is supported so the -server option is implicit  This is subject to change in a future release     The Server-Class Machine Detection page gives information on which VM is selected by OS and architecture   I don   t know how much of this applies to JDK 6

User · Answer

the -client and -server 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      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 gt 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  mywork classes com blogspot sdoulger LoopTest  Time spent  766    With -server   java exe -server -classpath C  mywork 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   Reference

User · Answer

From Goetz - Java Concurrency in Practice:

Debugging tip: For server applications, be sure to always specify the -server JVM command line switch when invoking the JVM, even for development and testing. The server JVM performs more optimization than the client JVM, such as hoisting variables out of a loop that are not modified in the loop; code that might appear to work in the development environment (client JVM) can break in the deployment environment (server JVM). For example, had we “forgotten” to declare the variable asleep as volatile in Listing 3.4, the server JVM could hoist the test out of the loop (turning it into an infinite loop), but the client JVM would not. An infinite loop that shows up in development is far less costly than one that only shows up in production.

Listing 3.4. Counting sheep.

volatile boolean asleep; ... while (!asleep) countSomeSheep();

My emphasis. YMMV

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

This is really linked to HotSpot and the default option values  Java HotSpot VM Options  which differ between client and server configuration  From Chapter 2 of the whitepaper  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  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 release of jdk6 update 10  see Update Release Notes Changes in 1 6 0 10  tried to improve startup time  but for a different reason than the hotspot options  being packaged differently with a much smaller kernel   G  Demecki points out in the comments that in 64-bit versions of JDK  the -client option is ignored for many years  See Windows java command  -client   Selects the Java HotSpot Client VM  A 64-bit capable JDK currently ignores this option and instead uses the Java Hotspot Server VM

User · Answer

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

User · Answer

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

[java] Real differences between "java -server" and "java -client"?

Examples related to java

Examples related to jvm

Examples related to jvm-hotspot