Chapter 2

When to Use 64-bit

To explain the dual 32-bit and 64-bit support in the Solaris operating environment, Figure 2-1 shows them side-by-side. The system on the left supports only 32-bit libraries and applications on top of a 32-bit kernel using 32-bit device drivers. The system on the right supports the same 32-bit applications and libraries as on the left, but also supports 64-bit libraries and applications simultaneously on top of a 64-bit kernel that uses 64-bit device drivers.

Figure 2-1 The Solaris Operating Environment Architecture

For application developers, the major difference between the Solaris 64-bit and 32-bit operating environments is the C data type model used. The 64-bit version uses the LP64 model where longs and pointers are 64-bits. All other fundamental data types remain the same as in the 32-bit implementation, which is based on the ILP32 model where ints, longs, and pointers are 32-bit quantities. These models are explained in greater detail in Chapter 4, Converting Applications.

Few applications really require conversion. Most applications can remain as 32-bit applications and still run on the 64-bit operating system without requiring any code changes or recompilation. In fact, 32-bit applications that do not require 64-bit capabilities should probably remain 32-bit to maximize portability.

You might want to convert applications with the following characteristics:

Can benefit from more than 4 gigabytes of virtual address space
Are restricted by 32-bit interface limitations
Can benefit from full 64-bit registers to do efficient 64-bit arithmetic
Can benefit from the performance improvement that the 64-bit instruction set provides

You might need to convert applications with these characteristics:

Read and interpret kernel memory using libkvm, /dev/mem, or /dev/kmem
Use /proc to debug 64-bit processes
Use a library that has only a 64-bit version

Some specific interoperability issues require code changes. Similarly, if your application uses files larger than 2 gigabytes, you might want to convert it to a 64-bit application instead of using the large file APIs directly.

These items are explained further in the sections that follow.

Major Features

The major features of the 64-bit environment include support for:

Large virtual address space
Large files
64-bit arithmetic
Removal of certain system limitations

Large Virtual Address Space

In the 64-bit environment, a process can have up to 64-bits of virtual address space, that is, 18 exabytes. This is approximately 4 billion times the current maximum of a 32-bit process.

Note - Because of hardware restrictions, some platforms might not support the full 64-bits of address space.

Large Files

If an application requires only support for large files, it can remain 32-bit and use the Large Files interface. However, if portability is not a primary concern, you might want to convert the application to a 64-bit program to take full advantage of 64-bit capabilities with a coherent set of interfaces.

64-bit Arithmetic

Though 64-bit arithmetic has long been available in previous 32-bit Solaris releases, the 64-bit implementation now uses the full 64-bit machine registers for integer operations and parameter passing. This allows an application to take full advantage of the capabilities of the 64-bit CPU hardware.

System Limitations Removed

The 64-bit system interfaces are inherently more capable than some of their 32-bit equivalents. Application programmers concerned about year 2038 problems (when 32-bit time_t runs out of time) can use the 64-bit time_t. While 2038 seems a long way off, applications that do computations concerning future events, such as mortgages, might require the expanded time capability.

Interoperability Issues

The interoperability issues that require an application to be made 64-bit safe or changed to interoperate with both 32-bit or 64-bit programs can include:

Client/server transfers
Programs that manipulate persistent data
Shared memory

Kernel Memory Readers

Because the kernel is an LP64 object that uses 64-bit data structures internally, existing 32-bit applications that use libkvm, /dev/mem, or /dev/kmem do not work properly and must be converted to 64-bit programs.

`/proc` Restrictions

A 32-bit program that uses /proc is able to look at 32-bit processes, but is not able to understand all attributes of a 64-bit process; the existing interfaces and data structures that describe the process are not large enough to contain the 64-bit quantities involved. Such programs need to be recompiled as 64-bit programs in order to work with both 32-bit and 64-bit processes. This is most typically a problem for debuggers.

64-bit Libraries

32-bit applications are required to link with 32-bit libraries, and 64-bit applications are required to link with 64-bit libraries. With the exception of those that have become obsolete, all of the system libraries are provided in both 32-bit and 64-bit versions, though no 64-bit libraries are provided in static form.

Estimating the Effort of Conversion

After you've determined that your application should be converted to a full 64-bit program, it is worth noting that many applications require only a little work to accomplish that goal. The remaining chapters discuss how to evaluate your application and the effort involved in conversion.


	Chapter 2 When to Use 64-bit To explain the dual 32-bit and 64-bit support in the Solaris operating environment, Figure 2-1 shows them side-by-side. The system on the left supports only 32-bit libraries and applications on top of a 32-bit kernel using 32-bit device drivers. The system on the right supports the same 32-bit applications and libraries as on the left, but also supports 64-bit libraries and applications simultaneously on top of a 64-bit kernel that uses 64-bit device drivers. Figure 2-1 The Solaris Operating Environment Architecture For application developers, the major difference between the Solaris 64-bit and 32-bit operating environments is the C data type model used. The 64-bit version uses the LP64 model where longs and pointers are 64-bits. All other fundamental data types remain the same as in the 32-bit implementation, which is based on the ILP32 model where ints, longs, and pointers are 32-bit quantities. These models are explained in greater detail in Chapter 4, Converting Applications. Few applications really require conversion. Most applications can remain as 32-bit applications and still run on the 64-bit operating system without requiring any code changes or recompilation. In fact, 32-bit applications that do not require 64-bit capabilities should probably remain 32-bit to maximize portability. You might want to convert applications with the following characteristics: Can benefit from more than 4 gigabytes of virtual address space Are restricted by 32-bit interface limitations Can benefit from full 64-bit registers to do efficient 64-bit arithmetic Can benefit from the performance improvement that the 64-bit instruction set provides You might need to convert applications with these characteristics: Read and interpret kernel memory using `libkvm`, `/dev/mem`, or `/dev/kmem` Use `/proc` to debug 64-bit processes Use a library that has only a 64-bit version Some specific interoperability issues require code changes. Similarly, if your application uses files larger than 2 gigabytes, you might want to convert it to a 64-bit application instead of using the large file APIs directly. These items are explained further in the sections that follow. Major Features The major features of the 64-bit environment include support for: Large virtual address space Large files 64-bit arithmetic Removal of certain system limitations Large Virtual Address Space In the 64-bit environment, a process can have up to 64-bits of virtual address space, that is, 18 exabytes. This is approximately 4 billion times the current maximum of a 32-bit process. Note - Because of hardware restrictions, some platforms might not support the full 64-bits of address space. Large Files If an application requires only support for large files, it can remain 32-bit and use the Large Files interface. However, if portability is not a primary concern, you might want to convert the application to a 64-bit program to take full advantage of 64-bit capabilities with a coherent set of interfaces. 64-bit Arithmetic Though 64-bit arithmetic has long been available in previous 32-bit Solaris releases, the 64-bit implementation now uses the full 64-bit machine registers for integer operations and parameter passing. This allows an application to take full advantage of the capabilities of the 64-bit CPU hardware. System Limitations Removed The 64-bit system interfaces are inherently more capable than some of their 32-bit equivalents. Application programmers concerned about year 2038 problems (when 32-bit time_t runs out of time) can use the 64-bit time_t. While 2038 seems a long way off, applications that do computations concerning future events, such as mortgages, might require the expanded time capability. Interoperability Issues The interoperability issues that require an application to be made 64-bit safe or changed to interoperate with both 32-bit or 64-bit programs can include: Client/server transfers Programs that manipulate persistent data Shared memory Kernel Memory Readers Because the kernel is an LP64 object that uses 64-bit data structures internally, existing 32-bit applications that use `libkvm`, `/dev/mem`, or `/dev/kmem` do not work properly and must be converted to 64-bit programs. `/proc` Restrictions A 32-bit program that uses `/proc` is able to look at 32-bit processes, but is not able to understand all attributes of a 64-bit process; the existing interfaces and data structures that describe the process are not large enough to contain the 64-bit quantities involved. Such programs need to be recompiled as 64-bit programs in order to work with both 32-bit and 64-bit processes. This is most typically a problem for debuggers. 64-bit Libraries 32-bit applications are required to link with 32-bit libraries, and 64-bit applications are required to link with 64-bit libraries. With the exception of those that have become obsolete, all of the system libraries are provided in both 32-bit and 64-bit versions, though no 64-bit libraries are provided in static form. Estimating the Effort of Conversion After you've determined that your application should be converted to a full 64-bit program, it is worth noting that many applications require only a little work to accomplish that goal. The remaining chapters discuss how to evaluate your application and the effort involved in conversion.