64 bit arch

Java and
64-Bit
Architectures
by Marcus Lagergren, Henrik Ståhl and
Edwin Spear

BEA confidential, share under NDA only
October 2006

Java and 64-Bit Architectures

Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Why Do We Need 64-bit Architectures? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
64-bit Architectures, Operating Systems and Java Virtual Machines . . . . . . . . . . . . . . . . . . . . . .2
Benefits of 64-bit Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
64-bit is Already Making its Presence Felt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
64-bit is Not a Panacea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Migrating to 64-bit is Easy, but Has Its Issues, Too . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Is 64-bit Right for You? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Summary and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Java and 64-Bit Architectures iii

iv Java and 64-Bit Architectures


Abstract
The need to process massive amounts of data at ever-increasing speeds is
driving the IT industry towards 64-bit applications built on 64-bit architectures. In
the right context, 64-bit systems outperform their 32-bit counterparts because of
the ability to process huge datasets with relative ease. Examples of early
adopters of 64-bit technology include financial institutions, the insurance
industry and the scientific community-all enterprises the success of which
hinges on how quickly they can manipulate large amounts of data.
Despite all of the positives surrounding 64-bit architectures, the technology is
not a panacea. The move from 32 to 64-bits mean that program code and data
start occupying twice as much space, increasing memory footprint and causing
access to system memory to become a bottleneck. Java is particularly sensitive
to this since memory management is automated and operations like memory
allocation, object access and garbage collection all exert high pressure on the
memory system.
The cost of migrating an application to 64 bits also has to be accounted for.
Luckily, Java benefits greatly from its “write once, run everywhere” property.
Most of the time, it's as simple as switching the Java Virtual Machine to a 64-bit
version. However, migrating Java applications that use native (JNI) code to
64-bit requires a porting effort. Some developers are reticent to employ 64-bit
architectures in their enterprise as they perceive these challenges to mitigate
the benefits of the more robust 64-bit technology. Some broad guidelines for
choosing 64- or 32 bit are offered to help customers determine which option is
right for them.

Java and 64-Bit Architectures 1

J a va an d 6 4-Bit A rc hi tec tu re s

Why Do We Need 64-bit Architectures?
The ever-present need for more powerful Java applications processing larger amounts
of data in exponentially shorter intervals is a constant challenge not just to Java
developers, but to the manufacturers of the hardware and software on which those
applications run. Today, we are witnessing another step in the evolution of computer
machinery: the transition from 32-bit architectures to 64-bit architectures. For the past
decade-and-a-half, 32-bit processing was considered sufficient to run most enterprise
applications; however, today the changing business landscape has placed huge demands
put on these systems to grow commensurately and 64-bit architecture is seen as the way
to meet these demands.
Already, 64-bit hardware has become an industry standard, first introduced in high-end
CPUs such as IBM Power, Sun SPARC and Intel Itanium and more recently solidified
with the availability of such hardware as the AMD Opteron chips and Intel Xeon
EM64T chips. In addition to the plethora of 64-bit hardware available, most major
operating system vendors-including Microsoft, HP, IBM, Sun and the Linux
vendors-have introduced 64-bit versions of their products. Only in the Java Virtual
Machine world is the move to 64-bit lagging. Today, 64-bit JVMs are less common and
used primarily in systems with specific needs, such as for applications that require
massive memory heaps. However, interest in 64-bit JVMs is on the rise.
Thus the question: are 64-bit architectures right for you? Despite the claims and solid
evidence of 64-bit's power, the technology is still at a stage where not everyone, every
application, every enterprise will see its benefits.
This paper examines 64-bit architectures and discusses some real-life examples of how
building applications on 64-bit systems has dramatically improved performance and
company profitability. It will also discuss the issues that might dissuade an organization
from implementing 64-bit solutions within their enterprise.

64-bit Architectures, Operating Systems and Java Virtual
Machines
Before choosing between 32 and 64-bit systems, it is important to understand the
ramifications of how each system layer-hardware, operating system, and JVM-impacts,
and is impacted by, the other layers. Choosing the right configuration of the layers is
more than just a question of whether or not to exploit the capabilities of 64-bit over 32.
Instead, the user needs to first consider the various deployment alternatives available
and which of those alternatives best meets their needs. These deployment alternatives
are shown in the following diagram:

2 Java and 64-Bit Architectures

Benefits of 64-bit Ja va

As the diagram shows, 64-bit support in a lower layer (for example, the hardware layer)
allows the user to choose between 32- and 64-bit in a higher layer; however, a user
cannot run 32-bit in a lower layer and 64-bit in a higher one.
From the Java application's perspective, the first two options in the preceding diagram
(that is, when a 32-bit operating system is used) are identical. The hardware's 64-bit
features will not be used. However, when a 64-bit operating system is installed, the user
can choose between a 32- and 64-bit JVM, and the only configuration that allows a
64-bit JVM is when the entire stack is 64-bit enabled.

Benefits of 64-bit Java
64-bit is becoming the preferred architecture for enterprise Java systems processing
large amounts of data. The basis for this statement is data size: many of today's
applications must process ever-increasing amounts of data and 64-bit architectures can
handle those larger datasets much more efficiently than 32-bit systems. Generally
speaking, a 32-bit system can directly address about 4 GB of data. Today, many
applications are exceed 4 GB in size and require a far more robust processing capability.
Enter the 64-bit architecture.
Systems running on 64-bit architectures can access and manipulate amounts of memory
that dwarf the capacity of their 32-bit counterparts. When an application runs on 64-bit
architecture, each process can, theoretically, access more than 4 billion times the
memory accessible by 32-bit processors (642 vs. 322). In addition, the current
implementation of 64-bit architectures allows the addressing of an equally massive
amount of physical memory. Even if the practical limit is often smaller, it is still a huge
amount of memory, and the ability to access and use that amount is what makes 64-bit
architectures so desirable.



The capability to use huge amounts of memory also makes garbage collection-a
common bottleneck in Java applications-more efficient. The aforementioned virtual real
estate available to 64-bit architectures means that larger heaps are available for object
allocation. As a rule, the rate of object allocation is high; however when the heap is full,
garbage collection must occur so that heap space can be freed, allowing the application
to continue to run. The smaller the heap, the more frequent the garbage collection; thus,
the larger the heap, the less often garbage collection is required. Since garbage
collection represents a performance hit, reducing the number and duration of these
collections is key to a highly performing application. Moreover, a larger heap can allow
the JVM more flexibility in finding a less intrusive point at which to collect garbage.
This is why the large heaps afforded by 64-bit architectures are desirable.
This reduction in overhead is clearly illustrated in the following chart, which is based on
data gathered by Intel. The chart shows how, as heap size increases, the overhead
required for garbage collection decreases. Notice that garbage collection on a heap of
1.5 GB is nearly five times as expensive as that on a heap of 13.5 GB; the math is simple:
by using a 64-bit architecture, your application cannot only avail itself of a much larger
heap for object allocation, but the overhead of maintaining that heap is significantly
cheaper.

The preceding graph demonstrates that a larger heap leads to higher system throughput.
However, another property that is important for many systems is system responsiveness,
which is impacted by GC pause times. Generally, the JVM needs to pause to collect
garbage and this pause time is dependent on two factors: the heap size and the amount


64-bit is Al re ady Making its Pres enc e Fe lt

of live data on the heap (non-garbage). Together these factors form a complex
relationship, but, in general, the outcome is that a very large heap means longer pause
times. On the other hand, a large heap allows caching larger amounts of data in memory,
which can decrease the need to access the disk or network-both operations that can
decrease responsiveness. When choosing between a 32- and a 64-bit JVM for a
response-time sensitive application, all of these parameters must be taken into account.
Data bandwidth is another area that demonstrates 64-bit's superiority over 32-bit. 64-bit
architectures can use wider registers, which allow them to perform operations on large
amounts of data per processor cycle. 32-bit systems might require using several registers
or, in the worst case, accessing system memory to perform the same operations. Also,
on some 64-bit architectures - specifically Intel Xeon EM64T and AMD Opteron - more
registers are available in 64-bit mode, which in itself provides a performance boost.
From this we conclude that any application that requires a large heap to cache or process
large amounts of data, and applications that do calculations on 64-bit data, can benefit
greatly from using a 64-bit stack.

64-bit is Already Making its Presence Felt
Already, a growing list of 64-bit customers has experienced great success with this latest
technological development. Financial institutions, such as banks and investment house,
with their ever-increasing need to handle more and bigger datasets in real-time and to
run expert systems, have shown to be a perfect fit for 64-bit architectures. So too has the
insurance industry, which makes great use of the larger architecture's ability to provide
more relevant actuarial statistics to help drive their profitability. 64-bit architectures
have also proven a boon to the scientific community as a solution to providing better
numerical analysis systems and geographical information systems. Additionally,
systems built on 64-bit architectures have proven extremely effective for managing data
warehouses and other implementations that require managing and manipulating massive
amounts of data quickly. Here are two examples of “wins” for 64-bit architectures:

Nielsen Outdoor measures the effectiveness of outdoor advertising channels such
as billboards, outdoor kiosks, and bus stops. To provide this kind of information
to their clients, they require an application that can handle datasets on the order of
24 GB with the possibility of a future demand for datasets as large as 108 GB.
Moreover, the application must handle an extremely large amount of
computations, ruling out the efficacy of disk-caching data for later use. This need
for larger datasets, combined with the ability to use this data quickly, was easily
solved by implementing their application on 64-bit architecture.

Handling larger datasets and providing near-instant response also drove a large
financial institution to transition from 32-bit architectures to 64-bit. This



institution provides risk calculations for currency trading, a process that requires
an expert system that can support huge heap sizes-up to 48 GB-while facilitating
real-time trades. Obviously, running on 32-bit and caching data to disk, while
providing the necessary storage, could not meet the performance requirements. By
building their system on a 64-bit chip running with a 64-bit enable JVM, they
were able to meet their requirements and provide useful, timely data to their
traders.

64-bit is Not a Panacea
The preceding sections have outlined the benefits of a 64-bit architecture to Java.
Enterprise servers supporting 64-bit have been available for 10 years or more, and have
become very widespread with the introduction of the Intel EM64T and AMD64
architecture. Operating systems with 64-bit support are becoming very common, and
64-bit JVMs are available. Despite this, to date, 64-bit Java has seen limited adoption.
Why is that?
While 64-bit architectures sounds like a simple solution to impending business
challenges, it is not a panacea. While 64-bit hardware and even 64-bit operating systems
are becoming more and more ubiquitous, there is still a lag in the JVM world, creating
issues with running this powerful technology, issues that might lead some to believe that
enduring the limitations of 32-bit architectures (vis-à-vis 64-bit) poses fewer drawbacks
to their success than they would face implementing current 64-bit systems. The chief
culprit here is, paradoxically, also 64-bit's key feature: its ability to handle large sets of
data.
First of all, because Java a garbage-collected language, it is particularly sensitive to
dataset size. This means that applications built on 64-bit architectures must be designed
to handle the large datasets available to them. Garbage must be collected quickly with
minimal pause times; object access times need to be minimized. For example, pause
times considered minimal on most applications might be undesirably long or impede
required performance of real-time systems, a prime target for 64-bit architectures. In this
case, system design would need to severely restrict how long pauses can last and how
often they should occur. Moreover, any special needs dictated by a requirement of
real-time response must be addressed. Failure to meet any of these objectives can result
in an application that cannot efficiently handle the amount of data that you might, by
virtue of your 64-bit architecture, want processed. The result is a poorly- or even a
non-performing application.
Another issue developers need to address is pointer size: 64-bit pointers are twice the
size of a 32-bit pointer and applications run on a 32-bit architecture will automatically
get bigger when ported a 64-bit system. Beyond the physical reality that loading and
storing 64-bit pointer data occurs more slowly than it does with 32-bit architectures,


M i g ra t i ng t o 6 4- b i t i s Easy, but Has Its I ssues, Too

64-bit pointers also use cache less efficiently than their 32-bit counterparts, which
consume less space in the cache. This is a problem because, with 64-bit data structures
shuffling larger amounts of data, the risk of cache misses-and their often severe impact
on system performance-increases commensurately.
To summarize, applications that exert high pressure on the system memory but without
benefiting from a large heap will perform slower in 64-bit mode. Many or most legacy
enterprise Java applications fall in this category.

Migrating to 64-bit is Easy, but Has Its Issues, Too
If you are currently running a 32-bit system and want to port it to a 64-bit architecture
running on a 64-bit JVM, the process is relatively simple: basically, you just install the
application on the new architecture and run it; however, if your application uses 32-bit
JNI native code, you will experience problems. Java applications that use 32-bit JNI
native code can't run on 64-bit platforms with a 64-bit JVM. In order to port these
applications to new 64-bit platforms, you need to recompile the 32-bit native code to the
new platform, which requires the additional overhead of modifying the original
application. If you don't own the source code, this might not be possible.

Is 64-bit Right for You?
As outlined in this paper, some applications benefit from 64-bit and some do not.
Generally, you should follow these recommendations:
Use a 64-bit stack for applications that:

Need a Java heap larger than 4 GB

Exhibit a large garbage collection overhead when run with a small heap

Do a lot of calculations on 64-bit data (double precision floating point, long
integers)
Use a 32-bit stack when:

Memory allocation is high, but a small Java heap is sufficient

Short garbage collection pauses are important
Most legacy enterprise Java applications fall in the latter category, although this is
slowly changing as dataset sizes increase and software-including JVMs-continue to
improve their 64-bit behavior, alleviating some of the drawbacks. There is of course a
gray area for borderline applications that need heaps in the range of 3-4 GB.
The following sample benchmarks—all run with 1 GB heap—demonstrate this.



SPECjbb2005 is SPEC’s benchmark for evaluating the performance of server-side Java.
It is memory intensive, so running with a 64-bit JVM results in a significant
performance drop due to higher pressure on the memory bus.


Summary and Recommendations

SPECjvm98 is SPEC's benchmark suite for client-side Java performance. It contains a
mix of workloads and is, despite being dated, fairly representative of Java desktop
applications. It suffers from the overhead of 64-bit data but not as much as the extremely
memory-intensive SPECjbb2005 benchmark.
While the preceding benchmarks show the 32-bit system slightly outperforming its
64-bit rival, these statistics were generated using a relatively small heap (1 GB). Current
32-bit JVMs perform faster than 64-bit when the heap is small. However, as stated
earlier, a 64-bit JVM can outperform the 32-bit JVM if a very large heap is used. If it
does, and at what heap size, depends on the application.

SciMark 2.0 is a NIST benchmark for measuring floating point performance. It is
CPU-intensive and can benefit from wider registers and does not put much pressure on
the memory bus. This benchmark benefits slightly from using a 64-bit JVM.

Summary and Recommendations
64-bit Java brings numerous advantages, most importantly the ability to keep large
datasets in memory. This can provide a significant performance boost for the right
application. However, 32-bit Java still outperforms 64-bit in many cases when a small
Java heap is sufficient.
You should consider using a 64-bit JVM if:



Your application requires quick access to a large dataset, such as an in-memory
database or cache.

You determine that you have a large GC overhead with a small heap.

You have issues with bottlenecks in code that does calculations using many
variables on Intel EM64T and AMD64 hardware.

You must use a 64-bit JNI library.
Applications that do not have any of the properties above probably perform better with
a 32-bit JVM.


64 bit arch

More Related Content

Viewers also liked (11)

Similar to 64 bit arch (20)

Recently uploaded (20)

64 bit arch