You are definitely correct in referencing the Oracle FAQ that primitives do NOT increase, but the pointers (object references) do.

4+ years ago when I wrote this there were several situations I was in where misunderstanding existed as to why apps were running out of memory when switching from 32-bit to 64-bit, or why a 64-bit app required more memory than running in 32-bit mode.

Hence the writeup to basically provide a practical example of how to “calculate” the average increase in memory an application would need from going to 64-bit and more importantly to prove that it was something to be expected and not a “fault” of a given application. It is by no means concrete and it fully depends on what you’re doing in the app.

If an app has a single object that contains an primitive byte[10000000] array then obviously the “average” of my calculations will not apply, but that’s also not how most objects/primitives exist in typical apps.

Every app would need to do their own testing and every developer needs to understand the difference between primitives and objects in Java.

Hope this helps provide some context.

Ben

No you don’t need to recompile the java application. Java bytecode can be run in either 32-bit or 64-bit JVMs.

However, running the code on your new machine won’t automatically solve your problem – it’s the JVM arguments that define how much memory the application can use.

Just because the machine has 16GB or 32GB of ram does not mean the java application will have access to it. You must tell the JVM how much memory to allow it to access.

Official documentation can be found here: http://download.oracle.com/javase/6/docs/technotes/tools/windows/java.html

-Xmxn
Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is chosen at runtime based on system configuration. For more information, see HotSpot Ergonomics
Examples:
-Xmx83886080
-Xmx81920k
-Xmx80m

For example, the following will run the app and give it a maximum of 2gb that it can use:

java -Xmx2g com.myapp.MyMain

That can work on most 32-bit JVMs.

Or, to give 4gb you would do:

java -Xmx4g com.myapp.MyMain

To force an app to 32-bit or 64-bit it can typically be accomplished via arguments such as this:

java -d32 com.myapp.MyMain
java -d64 com.myapp.MyMain

The -server option does the same thing as -d64 on most (if not all) modern JVM installations.

Hope this information helps. Good luck with your app.

Ben

I’ve added a link to the bottom of the article with the source file. You’ll need to rename it from a .doc ending to .java again … WordPress won’t allow attaching a .java file.

It’s nothing fancy, but did the job in helping me to validate the memory discrepancies we were seeing in our environments.

Hope it helps in some way.

Ben

Very interesting article!

Could you add a link to the Java class you have used for your benchmarks?

I would like to test it on my new server with openSUSE 10.2 (64-bit)…

Thanks

Christian