Peter is a DZone MVB and is not an employee of DZone and has posted 155 posts at DZone. You can read more from them at their website. View Full User Profile

Odd Practices in Java

  • submit to reddit
There are a number of practices in Java which oddly baffle me. Here are but a few.

Using -Xmx and -Xms

The option -Xmx is widely used to set the maximum memory size. As noted in the Java HotSpot VM Options 
Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.
 So you would think that such a widely used option would not be non-standard any more.  In fact there is a standard option -mx and similarly -ms. I don't know why these standard options are not use more widely, or even documented.

Using NIO for non-blocking IO only

Non blocking IO was a new feature of NIO for sockets.  However, the default behaviour for NIO Socket is blocking. Files are only blocking in NIO. NIO2 provides an asynchronous interface, but does it by passing your request off to an ExecutorService (which is cheating really because it doesn't anything do what you can't do better already)

Personally I prefer blocking NIO. Its is only suitable when you have a low number of binary connections, but it is an option which doesn't get enough press IMHO.

Using the 32-bit JVM to save memory

The amount of memory you save with a 32-bit JVM is far less than you might think. Modern 64-bit JVMs use 32-bit references by default for up to 32 GB heap sizes. It is unlikely you want to have a larger heap size (if only to avoid very long Full GC times)

The 32-bit JVM still has a smaller object header than the 64-bit JVM, but the difference is fairly small.
The 64-bit JVM can use more, larger registers (on AMD/Intel x64 systems) and a much larger address space allowing you have less memory limitations.

Using threads to make everything faster

Using multiple threads can increase your CPU utilisation and reduce the impact of IO latency. It doesn't solve all performance problems. It won't make your disks go faster, increase your network bandwidth, the size of your L3 cache, increase you CPU to main memory bandwidth or make your database significantly faster.

Similarly making everything concurrent won't make so much difference either. Do you need 1000 concurrent collections when you only have 8 cores? No matter how many threads you have, only 8 of them will be running at once, and if you have 1000 collections its quite unlikely that two will be using the same collection.

Use concurrency selectively for critical resources. Otherwise you risk not only increasing overhead and slowing down your application, but far worse is the increase in complexity you introduce.
Published at DZone with permission of Peter Lawrey, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Pavel Bernshtam replied on Sun, 2012/07/01 - 11:57pm

java -help does not show any standard option -mx and -ms. I never saw such options. I'm using Sun JDK 1.6 on Linux

Jean Said replied on Mon, 2012/07/02 - 3:02am

For no clear reason, the 32 bit JVM does indeed uses much less space than the 64 bit on Linuxes. Tested with Eclipse mostly. Maybe it's just a bug in the native code, but the 64 bit version eats up memory like crazy.

-Xmx and -Xms have become become a defacto standard. AFAIK, no JVM supports dynamic adjustment of heap and stack size.

Threads are a different beast. I am still amazed at how many people think that monothreaded = slow. In my company, it has become a political subject that developpers here suck 'cause most of the backend code is mono threaded. And we are always telling them that IO and external communications are bogging down our system, we're not CPU bound.


Stephane Vaucher replied on Mon, 2012/07/02 - 1:32pm in response to: Jean Said

Loic - 64bit Linux VMs will take more memory than 32 bit VMs. Your statement lacks information to support your statement. Are you using hotspot? which version? Older versions require explicitly asking to use compressed oops. 

"In my company, it has become a political subject that developpers here suck 'cause most of the backend code is mono threaded. And we are always telling them that IO and external communications are bogging down our system, we're not CPU bound."

If you are IO bound by accessing external resources, you should benchmark. Unless you are saturating your network resources, you might increase performance in a multithreaded environment (e.g., you get data from all of your different remote data sources simultaneously).

Balint Persics replied on Tue, 2012/07/03 - 10:01am

This post is misleading. 

Among the standard VM options one cannot find -mx and -ms. See:


Peter Lawrey replied on Fri, 2012/12/21 - 4:47pm in response to: Pavel Bernshtam

 AFAIK In Java 1.1, the -ms and -mx where the only options.  However in Java 1.2 it was decided to make the options -Xms and -Xmx as non-stanard options so they could be dropped and changed in the future, but the old options were kept for backward compatibility and are still in Java 7.  Given there are "standard" options are still in Java 7 and they haven't been removed, the need for the "non-standard" options which do the same thing baffles me.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.