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
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. In the ILP32 model,
longs, and pointers
are 32-bit quantities. These models are explained in greater detail in Chapter 3, Comparing 32-bit Interfaces and 64–bit Interfaces.
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 through the use of 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 that are larger than 2 gigabytes, consider conversion to a 64-bit application instead of using the large file APIs directly.
These items are explained further in the sections that follow.
To explain the dual 32-bit and 64-bit support in the Solaris operating environment, the following figure shows the stacks side-by-side. The system on the left supports only 32–bit libraries and applications on top of a 32-bit kernel that uses 32-bit device drivers. The system on the right supports the same 32–bit applications and libraries as on the left. This system also supports 64-bit libraries and applications simultaneously on top of a 64-bit kernel that uses 64-bit device drivers.
The major features of the 64-bit environment include support for:
Large virtual address space
Removal of certain system limitations
In the 64-bit environment, a process can have up to 64–bits of virtual address space, that is, 18 exabytes. This virtual address space is approximately 4 billion times the current maximum of a 32-bit process.
Because of hardware restrictions, some platforms might not support the full 64–bits of address space.
If an application requires only support for large files, the application can remain 32-bit and use the Large Files interface. However, if portability is not a primary concern, consider converting the application to a 64-bit program. A 64-bit program takes full advantage of 64-bit capabilities with a coherent set of interfaces.
64-bit arithmetic has long been available in previous 32-bit Solaris releases. However, the 64-bit implementation now uses the full 64-bit machine registers for integer operations and parameter passing. The 64-bit implementation allows an application to take full advantage of the capabilities of the 64-bit CPU hardware.
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 that concern future events,
such as mortgages, might require the expanded time capability.
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 and server transfers
Programs that manipulate persistent data
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.
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 that are involved. Such programs need to be recompiled as 64-bit programs in order to work with both 32-bit processes and 64-bit processes. The ability to work with both 32-bit processes and 64-bit processes is most typically a problem for debuggers.
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 libraries that have become obsolete, all of the system libraries are provided in both 32-bit versions and 64-bit versions.
After you've decided to convert your application 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.