Porting Guide - Moving Java applications to 64-bit systems. 64-bit Java - general considerations

Transcription

1 Porting Guide - Moving Java applications to 64-bit systems IBM has produced versions of the Java TM Developer Kit and Java Runtime Environment that run in true 64-bit mode on 64-bit systems including IBM Power, IBM zseries and Itanium. This document is intended for programmers and it describes the process of porting Java applications that run on 32-bit systems to 64-bit systems. This document covers: General porting considerations Porting native code from 32-bit to 64-bit JNI considerations Usage of the JNI Interface JVMPI and JVMDI interfaces 64-bit Java - general considerations This section considers some of the issues involved in implementing Java as a true 64-bit process on a processor and operating system combination that offers an execution mode with 64-bit addressing, where address pointers are 64-bits and where accessible memory can be greater than 4GB. The IBM implementation of the Java platform on 64-bit processors IBM provides 64-bit implementations of the Java platform on a number of 64-bit platforms. Why is there a need for 64-bit versions of the Java technology? The size of the addresses on the underlying processor or operating system is not visible or relevant to Java applications, because the Java language and the Java environment do not have explicit pointers that reference memory locations. So you might think that a 64- bit implementation of Java is not necessary. One reason for having a 64-bit Java implementation is that the Java environment must be able to run within the context of a 64-bit system and Java must be able to exploit the capabilities of the system. There are Java programs that have to run within the process of a 64-bit application or subsystem. An example of this occurs where a Stored Procedure is implemented using the Java platform within a database such as IBM s DB2. There might also be the need for a Java application to use native code through Java Native Interface (JNI) where the Native Code is 64-bit. An example of this is a Java application that uses a Java Database Connectivity (JDBC) driver that is written in 64-bit native code on a 64-bit platform. A third reason is the need for a Java application to exploit the large amounts of data possible for large memory systems. The Java heap space (where all Java objects are held at runtime) must be greater than the 4GB maximum size possible on a 32-bit system for this to be possible. To satisfy each of these cases, it is necessary for the Java Runtime Environment to be implemented as a true 64- bit process on a 64-bit system. The Java API and porting native code The way that Java applications run on a 64-bit Java implementation is shown in Figure 1. This diagram is helpful in identifying significant components and it helps you to understand which items need to change when porting applications from 32-bit to 64-bit. All Java applications are written to a defined Java application

2 programming interface (API). This API is the same for all Java 2 Standard Edition (J2SE) implementations, whether they are 32-bit or 64-bit. Java Application Code API awt net lang rmi Java Class Libraries 64-bit Java VM Native Code JIT Heap HPI Layer JNI JVMPI JVMDI 64-Bit Process Operating System Figure 1. Java Applications running on a 64-bit System The Java API includes the various Java class libraries (for example, awt, swing, net, io, and rmi) that are supplied as a fundamental part of Java 2 SE. The Java API - and all of the Java code - is exactly the same on a 64-bit implementation as it is on a 32-bit implementation. It is this characteristic of the Java code that enables it to deliver the promise of write once, run anywhere. In other words, if you have Java program code that runs on a 32-bit Java system, it runs unchanged on a 64-bit system. If your Java application is written 100% in the Java language, porting from 32-bit to 64-bit systems is very simple. Your 100% Java application will run unchanged - it will not even require to be recompiled.

3 Many Java applications are not written 100% in the Java language. For these applications, some of their code is written in a non-java language, such as C or C++, which is generally referred to as native code. Porting Java applications that have native code takes more effort. All the Java code (the application and the class libraries) is executed by the Java Virtual Machine (Java VM). The Java VM contains subcomponents that run the Java code and manage the data in the Java Heap. The IBM version of the Java VM includes a state-of-the-art just-in-time compiler (JIT) that compiles the Java code into native processor instructions before execution. In this way, the JIT maximises the performance of the code. In a 64-bit implementation of the Java environment, it is the Java VM that is implemented as a 64-bit program and that is aware of the 64-bit nature of the underlying processor. This includes the JIT compiler, which must compile the Java code to use 64-bit addresses. The JIT compiler is also aware of the full 64-bit instruction set available on the underlying processor. In IBM s implementation of J2SE, the Java VM communicates with the operating system through the Host Porting Interface (HPI). This communication makes the Java VM code independent of the underlying operating system and allows the IBM implementation of J2SE to support a range of operating systems on a given processor type. IBM implementations of J2SE Version and later are available in 64-bit mode for the following combinations of processor and operating system: Processor Type IBM Power series IBM zseries Intel Itanium series Operating Systems supported AIX, Linux Linux Microsoft Windows, Linux JNI and native code The Java VM, the HPI layer, and the Java code all execute within a single 64-bit operating system process. Normally, there is some native code that executes within that same process. The native code is one or more libraries of code compiled directly for the processor and operating system. The native code is accessed from Java code through the Java Native Interface (JNI). The native code can also access Java objects and methods through the JNI. Some native code is part of the J2SE implementation, such as the code that implements the Java awt classes using the graphics and windowing functions provided by the operating system. Other native code may be provided as part of an application. There are two other interfaces which are similar in nature to the JNI: the Java Virtual Machine Profiling Interface (JVMPI) and the Java Virtual Machine Debugging Interface (JVMDI). These interfaces provide capabilities for the Profiling and Debugging of Java applications. To use these capabilities, you must write some native code. In the case of the 64-bit implementations of J2SE, all the native code associated with the 64-bit Java VM must be 64-bit, because it all runs in the same process space as the JVM. It is not possible to run 64-bit code and 32- bit code within the same process space because of the incompatibility of the address sizes between these two types of code. Native code, typically written in the C or C++ languages, is directly aware of the size of addresses. If your application has native code, the native code must be ported from a 32-bit system to a 64-bit system. Native code must be recompiled and relinked for the 64-bit system. Native code needs to be modified to

4 work correctly with 64-bit addresses and other related differences between 32-bit and 64-bit environments. In summary, the 64-bit Java VM implementation runs on a 64-bit processor and links to code that is also 64-bit aware. The Java VM is also able to use the large memory support and 64-bit instructions of the underlying processor. The Java applications it runs are exactly the same as those that can run on 32-bit implementations of Java. Only native code must be ported from 32-bit systems to 64-bit systems. The advantage of Java programs when moving from 32-bit to 64-bit The Java language and environment make the transition from 32-bit computing to 64-bit computing particularly straightforward. For programs written in languages that have explicit address pointers, such as C and C++, porting an application from 32-bit to 64-bit can take considerable effort. This is because every pointer must be redeclared as a 64-bit quantity and any calculation concerning addresses must be checked carefully and adjusted to ensure that it executes correctly in the 64-bit environment. By contrast, Java programs do not even require to be recompiled in order to run correctly in the 64-bit environment. For Java programs, all the hard work is done by the Java VM implementation. The underlying pointer size is hidden from view. Porting native code from 32-bit to 64-bit Where a Java application has native code, the main task in porting the native code from a 32-bit system to a 64- bit system involves making the native code work correctly in the 64-bit environment. A second task involves the changes needed in the native code to work with the 64-bit versions of the JNI, JVMPI, and JVMDI, where there are a few subtle changes. You should consult the documentation relating to your operating system platform and to your C/C++ Compiler on the changes needed to port code from 32-bit to 64-bit, but here is a summary of the changes for Windows, Linux and AIX: v For Windows, on 32-bit systems, integers, longs and pointers are all 32-bits. On 64-bit systems, integers and longs remain 32-bits, but pointers become 64-bits and long longs are 64-bits. v For AIX and Linux, on 32-bit systems, integers, longs and pointers are all 32-bits. On 64-bit systems, integers remain 32-bits and longs and pointers become 64-bits. All native code must be adjusted to work with these differences introduced by the 64-bit systems. The best way to do this is to make changes that allow a single copy of the source code to be compiled either for a 32-bit target system or for a 64-bit target system. Although there is no one best way to achieve this goal, a good way to achieve this is to use abstract types for any integers that need to be of the same size as a pointer. For example, when making address calculations, the abstract integer types map either to 32-bits or to 64-bits depending on the size of a pointer. On Unix systems (AIX or Linux), care must be taken with the use of long types. The best advice is to avoid the use of long integers because they are known to change size between 32-bit systems and 64-bit systems. Another important consideration when porting native code to 64-bit systems is that data types must be correctly aligned. Incorrect alignment can cause serious loss of code performance. Correct alignment for the various data types is as follows: AIX, Linux 32-bit AIX, Linux 64-bit Windows 32-bit Windows 64-bit

5 C/C++ Data Types Size/Alignment Size/Alignment Size/Alignment Size/Alignment char 1/1 1/1 1/1 1/1 short 2/2 2/2 2/2 2/2 int 4/4 4/4 4/4 4/4 long 4/4 8/8 4/4 4/4 long long 8/8 8/8 8/8 8/8 pointer 4/4 8/8 4/4 8/8 float 4/4 4/4 4/4 4/4 double 8/4 8/4 8/8 8/8 long double 16/16 16/16 8/8 8/8 When the native code has been adjusted to take account of the differences between 32-bit systems and 64-bit systems, you must tune the code to accommodate differences in the interfaces to the Java VM - the JNI, the JVMDI and the JVMPI. JNI considerations The main consideration in using JNI from native code on a 64-bit system is that length-related quantities in JNI are defined as 64-bits. This is true even though the underlying objects and quantities within the Java Developer Kit (JDK) are restricted to values no greater than 32-bits. An error occurs if native code uses values greater than 32 bits for these quantities. The definition of JNI is held in two header files, which are included by any native code using JNI - jni.h and jni_md.h. In a 64-bit version of the JDK, the JNI interface itself changes as follows: v All pointers (foo *) become 64-bit. v <jni_md.h> jint This is defined as a 32-bit value (int), since on Unix systems a long is a 64-bit integer. v <jni.h> jsize. This type is used extensively for quantities that imply lengths. This is changed on 64-bit systems to a jlong so that it is 64-bits, in contrast to the definition on 32-bit platforms where it is a jint, which is 32-bits. v jfloat and jdouble values remain the same as in 32-bit systems. v a jobject is defined as a pointer and so is clearly 64-bit.. v jclass, jthrowable, jstring and jarray are all declared as jobjects and are all 64-bit. v jvalue is a union of all basic 'j' types and is already 64-bit. v jmethodid and jfieldid are declared as pointer types and are 64-bit quantities. v JNINativeMethod struct is 3 pointers and becomes 24 bytes. v JNIEnv is declared as a pointer type and is 64-bit. v JavaVM is declared as a pointer type and is 64-bit. v JNINativeInterface is declared as an array of pointers and these are all 64-bit. v DefineClass has a buffer parameter with an associated size parameter. The size parameter is declared as a jsize and therefore is a 64-bit integer length. However, class objects cannot be this large, so there is an upper bound to the value of the size parameter and is less than 32-bits. v PushLocalFrame has a capacity defined by a jint and is limited to 32-bits.

6 v EnsureLocalCapacity has a capacity defined by a jint and is limited to 32-bits. v NewString has a jsize length parameter and becomes 64-bit. However, the size of the supplied unicode string has a maximum length no greater than a 32-bit integer. v GetStringLength returns a jsize, which is 64-bit. The length of a Java string is limited to 32-bit integer values. v GetStringUTFLength returns a jsize, which is 64-bit. The length of a Java string is limited to 32-bit integer values. v GetArrayLength returns a jsize, which is 64-bit. However, Java arrays cannot have a length greater than a 32-bit integer value. v NewxxxArray (eg NewBooleanArray) all have jsize length parameters, which are 64-bit. Java arrays cannot have a length greater than a 32-bit integer value. v GetObjectArrayElement, SetObjectArrayElement both have jsize index values which are 64-bit. Java arrays cannot have a length greater than a 32-bit integer. v GetxxxArrayRegion, SetxxxArrayRegion all have jsize start and length fields, which are 64-bit. (xxx here stands for the various types of primitives such as int or float) Java arrays cannot have a length greater than 32- bit integer value. v RegisterNatives has a jint parameter - number of methods. v GetStringRegion, GetStringUTFRegion both have start and length parameters as jsize, which are 64-bit. Strings are limited to 32-bit lengths. v JavaVMOption struct has two pointers: both become 64-bit. v JavaVMInitArgs struct: alignment is affected by change to JavaVMOption struct. v JavaVMAttachArgs alignment is affected by two pointers. Usage of JNI Interface Beyond the form of the JNI interface, you must consider how the JNI is used by native libraries on a 64-bit system. The issues are as follows: On some 64-bit systems, certain native objects that are passed across the JNI are 64-bit, whereas they are 32- bit on equivalent 32-bit systems. Examples of this type of object are Socket handles and File handles. v Passing the 64-bit items across the JNI is not a problem. However, in many cases, these items are stored into Java object fields. The implication is that the type of these object fields must change on a 64-bit platform compared with existing 32-bit platforms. You will have to change parts of the Java code to achieve this. v If the size of a Java object field is different on the 64-bit platform from the 32-bit platform, any native code that is working with that object field must be changed to reflect this when the code is ported from 32-bit to 64- bit. You can best deal with this issue by having a proper description of each of the Java object types that is affected in this way. If your application code stores native data within Java objects, then you need to modify your Java code to ensure that there is sufficient space within your Java objects to store the full size of the native data.

7 JVMPI and JVMDI interfaces Applications may have native code that uses the JVMPI and JVMDI interfaces. These interfaces are also affected by the change from 32-bit to 64-bit as described in this section. JVMPI interface The JVMPI interface is defined in the header file jvmpi.h. The following changes have been made to the interface definition: 1. struct { unsigned char *class_data; /* content of class file */ jint class_data_len; unsigned char *new_class_data; /* class file length */ /* instrumented class file */ jint new_class_data_len; /* new class file length */ void * (*malloc_f)(size_t); } class_load_hook; /* memory allocation function */ This definition is the same as the definition on IBM 32-bit Java implementations. However, it differs from the Sun specification in relation to the definition of the memory allocation function. Defining the memory allocation function with a size_t type parameter actually enables this structure to work unchanged on 64-bit systems, because size_t becomes 64 bits. 2. struct { jint arena_id; jobjectid class_id; /* id of object class */ jint is_array; /* JVMPI_NORMAL_OBJECT,... */ jsize size; /* size in number of bytes */ jobjectid obj_id; /* id assigned to this object */ } obj_alloc; Here, the size field becomes jsize in type, which is 64 bits on 64-bit systems, but 32 bits on 32-bit systems. 3. struct { jsize data_len; char *data; } object_dump; Here, the data_len field becomes jsize in type, which is 64 bits on 64-bit systems, but 32 bits on 32-bit systems. Remember that the JVMPI interface is a flexible interface that is typically extended beyond the basic set of function. This is true for IBM 64-bit Java implementations as well as for the IBM 32-bit Java implementations. JVMDI interface The JVMDI interface is defined in the header file jvmdi.h. The JVMDI Interface has no changes for 64-bit, other than changing Pointer parameters to 64-bit from 32-bit. All JVMDI structures and function call definitions remain the same in 64-bit as they are in 32-bit.

8 Trademarks Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. IBM is a registered trademark of IBM Corporation. AIX is a trademark of IBM Corporation.