32-bit or 64-bit?

64 bit architectures are around for some times now. This blog entry is my response to the following question asked by couple of IT managers recently.

Will J2EE application deployment benefit from 64-bit technology?

Here’s my response after scouring through various resources.

Java/J2EE is a layered architecture. Layers from bottom to top are processor hardware, operating system, JVM, application server, custom applications. It is very important to look at each layer of the architecture to understand its role in 64-bit architecture.

Processor Hardware

Several processor architectures offer 64-bit computing power – Itanium 64-bit, AMD64, Xeon 64 bit, SPARC etc. Irrespective of the architecture 64-bit hardware offers following common benefits over their 32-bit counterpart.

a) In 32-bit Java heap memory allocation is limited by ~2G. 64-bit memory addressing gives virtually unlimited heap allocation and It is only limited by available physical and swap memory of the server.

b) 64-bit hardware has 64 bits data path between CPU and RAM.

It is also worth to note that, other than memory allocation advantages 64-bit hardware is not expected to give better performance than 32-bit counterpart with similar architecture and speed.

Operating System

Most of the mainstreams operating systems support one ore more processor architectures.

Specifically for WebLogic applications, BEA certifies several 64-bit configurations.

The operating systems for those 64-bit architectures generally support both 32-bit and 64-bit applications.

JVM

In addition of the processor and operating systems, JVM plays a critical role in overall performance of the 64 bit architectures.

An article on Dev2Dev about Jrockit JVM and Itanium processor gives good insight about JVM capabilities to exploit 64-bit hardware’s computing power.

For given application platform configuration one or more options are available for JVM. Larger heap allocations result in greater overhead on garbage collection performance. Each JVM has more than GC options targeted for large heap allocations.

It is also important to note that other than higher memory allocations, for a given 64 bit hardware and OS 64-bit JVM is not expected to offer significant performance gain over 32-bit JVM running on same 64 bit hardware and OS. Sun 64-bit JVM performance is lower than 32-bit JVM, while BEA JRockit 64-bit performance is marginally better than 32-bit version in reported benchmark data.

It is recommended to run your own benchmarks to measure 64-bit performance gain, select JVM and ideal GC scheme.

Application Characteristics and Architecture

At last answers of following questions will also help if you are considering investment in 64-bit architecture.

a) Is application's performance really constrained by java heap size limit (~2G)?

In J2EE and java world more resources (heap memory, threads etc) do not translate in higher performance every time. Most of the large J2EE applications can scale very well by running multiple instances (with "<2g").>

b) Will application architecture really benefit from - 64 bit arithmetic, wider data path?

If application is not memory bound, it will not benefit. Most of the J2EE applications are I/O bound.

c) Is application architected to leverage 64-bit benefits?

Most of the large application can scale without having large heap size of the individual application instances. Nevertheless possibility of the large heap allocations opens up new opportunities to take application's performance next level. Application can implement large data cache by custom cache implementation or using third party caching products to cut down database I/O calls significantly.