Experience of moving to 64 bit JVM

Question

Our company is planning to move to 64 bit JVM in order to get away from 2 GB maximum heap size limit. Google gave me very mixed results about 64 bit JVM performance. Has anyone tried moving to 64 bit java and share your experience

Answer 1

We've written directly to 64bit and I can see no adverse behavior...

Answer 2

Works fine for us. Why don't you simply try setting it up and run your load test suite under a profiler like jvisualvm?

Answer 3

If you need the larger heap, then questions of performance are rather moot, aren't they? Or do you have a plan for horizontal scaling?

The main problem that I've heard with 64-bit apps is that a full garbage collection can take a very long time (because it's based on number of live objects). So you want to carefully tune the GC parameters to avoid full collections (I've heard one anecdote about a company that had 64 Gb of heap, and tuned their GC so that they'd never to a full GC; they'd simply shut down once a week).

Other than that, recognize that Java is 32-bit by design, so you're not likely to see any huge performance increase from moving data 64 bits at a time. And you're still limited to 32-bit array indices.

Answer 4

In a nutshell: 64-bit JVMs will consume more memory for object references and a few other types (generally not significant), consume more memory per thread (often significant on high-volume sites) and enable you to have larger heaps (generally only important if you have many long-lived objects)

Longer Answers/Comments:

• The comment that Java is 32-bit by design is misleading. Java memory-addressing is either 32, or 64-bit, but the VM spec ensures that most fields (e.g. int, long, double, etc.) are the same regardless.

• Also - the GC tuning comments while pertinent for number of objects, may not be relevant, GC can be quick on JVMs with large heaps (I've worked with heaps up to 15GB, with very quick GC) - it depends more on how you play with the generational collector schemes, and what your object usage pattern is. While in the past people have spent lots of energy tuning parameters, it's very workload dependent, and modern (Java 5+) JVMs are very good at self-tuning - unless you have lots of data you're more likely to harm yourself than help with aggresive JVM tuning.

• As mentioned on x86 architectures, the 64-bit EMT64 or x64 processors also include new instructions for doing things like atomic writes, or other options which may also impact high-performance applications.

Answer 5

Naively taking 32 bit JVM workloads and putting them on 64 bit produces a performance and space hit in my experience.

However, Most of the major JVM vendors have now implemented a good technology that essentially compresses some of the heap - it's called compressed references or compressed oops for 64 bit JVMs that aren't "big" (ie: in the 4-30gb range).

This makes a big difference and should make a 32->64 transition much lower impact.

Reference for the IBM JVM: link text