64 bit arch

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

BEA confidential, share under NDA onlyOctober 2006

Java and 64-Bit Architectures iii

Java and 64-Bit Architectures

Java and 64-Bit ArchitecturesAbstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .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

iv Java and 64-Bit Architectures

Java and 64-Bit Architectures 1

Java and 64-Bit Architectures

AbstractThe 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-Bi t A rch i tec tu res

2 Java and 64-Bit Architectures

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:

Benef i ts o f 64-b i t Java


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 Java64-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-b i t i s A l ready Mak ing i ts P resence Fe l t


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 FeltAlready, 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 PanaceaThe 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,

Migrat ing to 64-b i t i s Easy , but Has I ts 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, TooIf 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 Recommendat ions


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 Recommendations64-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.

Technology

64 bit arch