Battling Java heap size, big difference between Java locally and Java web start

Question

I had a call of a customer last weekend telling me their Java program was not responding when doing an import of data. The data is a simple Excel workbook with 4 worksheets. All data is being read from the columns and added to a database.

So I started to investigate and had some strange results.

1. Testing the import by using Run in Netbeans. This uses Java 64-bit instance:

First run

Second run

2. Testing the import by using Java Web start. This is being launched by opening a JNLP file and uses a Java 32-bit instance:

First run

In this case I had the same issue which the customer was reporting, the program stopped responding after a while going through the import process. This is caused because I'm reaching the max heap size as far as I can tell (red circle).

Second run

So I've decided to increase the initial heap size and max heap size by adding the following to my JNLP file: initial-heap-size="512m" max-heap-size="1024m". When I tested the import again, it seemed to work, however I notice there is much more memory used compared to the first 2 cases:

• Why is there a 300mb difference in memory usage between case 1 and 2 compared to case 4?
• Is this high memory usage the result of bad programming or a memory leak? Or is it normal to have such high values?
• Is adding initial-heap-size="512m" max-heap-size="1024m" a valid solution for this issue?

Answer 1

Well, the obvious differences are that your first runs are done with a 64-bit server VM and the latter ones are done with a 32-bit client VM.

Supposedly the client VM is optimized for better usability in a desktop type application, and the server VM is optimized for "server" work. I don't have a full list of the differences (or whether it's really something that works out well in actual use cases). Don't quote me on this, but I do believe that the client VM avoids GC more than the server VM, because it was at least at one point perceived as slow. That would explain why the client VM is using a lot more memory, instead of aggressively releasing it.

Fiddling with the GC parameters is sometimes the correct thing to do, and in this case it's pretty much the only thing you can do, unless you identify any significant memory leaks. It's not a bad idea to be familiar with what makes the GC tick in any case though.