Which heap size do you prefer ?

Question

I know there is no "right" heap size, but which heap size do you use in your applications (application type, jdk, os)?

Answer 1

Typically i try not to use heaps which are larger than 1GB. It will cost you on major garbage collections.

Sometime it is better to split your application to a few JVM on the same machine and not you large heap sizes.

Major collection with a large heap size can take >10 mintues (on unoptimized GC applications).

Answer 2

Actually I always considered it very strange that Java limits the heap size. A native application can usually use as much heap as it wants, until it runs out of virtual address space. The only reason to limit the heap in Java seems the garbage collector, which has a certain kind of "laziness" and may not garbage collect objects, unless there is a necessity to do so. That means if you choose the heap too big, your app constantly uses more memory than is really necessary.

However, Sun has improved the GC a lot over the years and to emulate the behavior of a native C app, I would set the initial heap size to 32 MB (for small programs) or 64 MB (for bigger ones) and the maximum to something between 1-2 GB. If your app really needs over a 1 GB of memory, it is most likely broken (unless you deal with data objects that large), but I see no reason why your app should be killed, just because it goes over a certain heap size.

Of course, this is referring to normal PCs. If you create Java code for mobile phones or other limited devices, you should probably adopt the initial and maximum heap size to the limitations of that device.

Answer 3

This is entirely dependent on your application and any hardware limitations you may have. There is no one size fits all.

jmap can be used to have a look at what heap you are actually using and is a good starting point for right-sizing the heap.

Answer 4

You have to try your application and see how it performs. for example, I used to always run IDEA out of the box until I've got this new job where I work on this huge monolithic project. IDEA was running very slow and regularly throwing out of memory errors when compiling the full project.

first thing I did is to ramp up the heap to 1 gig. this got rid of the out of memory issues but it was still slow. I also noticed IDEA was regularly freezing for 10 seconds or so after which the used memory was cut in half only to ramp up again and , and that triggered the garbage collection idea. I now use it with -Xms512m, -Xmx768m but, I also added -Xincgc, to activate incremental garbage collection

As a result, I've got my old IDEA back: it runs smooth, doesn't freeze anymore and never uses more than 600m of heap.

For your application you have to use a similar approach. try to determine the typical memory usage and tune your heap for the application to run well in those conditions. But also let advanced users tune the setting, to address out of the ordinary data loads.

Answer 5

It depends on the application type. A desktop application is much different than a web application. An application server is much different than a standalone application.

It also depends on the JVM that you are using. JDK5 and later 6 include enhancements that help understand how to tune your application.

Heap size is important, but its also important to know how it plays with the garbage collector.

JDK1.4 Garbage Collector Tuning

JDK5 Garbage Collector Tuning

JDK6 Garbage Collector Tuning

Answer 6

You need to spend quite some time in JConsole or visualvm to get a clear picture on what the plateau memory usage is. Wait until everything is stable and you see the characteristic sawtooth curve of heap memory usage. The peaks should be your 70-80% heap, depending on what garbage collector you use.

Most garbage collectors trigger full GCs when heap usage reaches a certain percentage. This percentage is from 60% to 80% of max heap, depending on what strategy is involved.

Answer 7

1.3Gb for a heavy GUI application.

Unfortunately on Linux the JVM seems to pre-request 1.3G of virtual memory in that situation, which looks bad even if it's not needed (and causes a lot of confused grumbling from users)

Answer 8

On my most memory intensive app:

-Xms250M -Xmx1500M -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC