---

The Java VM for Mac OS X

The foundation of any Java implementation is the Java virtual machine (VM). The Java implementation for Mac OS X includes the Java HotSpot VM runtime and the Java HotSpot client VM from Sun. The VM options available with the Java VM in Mac OS X vary slightly from those available on other platforms. The available options are presented in Java Virtual Machine Options.

Contents:

Basic Properties of the Java VM
Mac OS X Java Shared Archive

Basic Properties of the Java VM

Table 1 lists the basic properties of the Java VM in Mac OS X. You can use System.getProperties().list(System.out) to obtain a complete list of system properties.

Mac OS X Java Shared Archive

To help increase the speed of application startup and to reduce the memory footprint of Java applications, the Java VM in Mac OS X makes use of a Java shared archive (JSA). The JSA contains the preprocessed internal HotSpot representations of common standard Java classes that would otherwise be found and processed from the standard classes.jar file. Since this data doesn’t change, it can be shared across processes by mapping the JSA file directly into shared memory. The JSA file is created upon first system boot after installation of Java. Since each Java application does not need to generate an independent archive at runtime, less memory and fewer CPU cycles are needed. There is nothing you need to do programatically to take advantage of these advances. A brief description of this technology is provided here.

Generational Garbage Collection

Garbage collection (GC) is the means whereby the Java VM gets rid of objects that are no longer in use. Java provides an environment to the programmer where objects and the memory that they use are automatically reclaimed without programmer intervention. This runtime facility, GC, has been under development for decades. The basic ideas is that there is a set of root objects that reference other objects which in turn reference other objects and so on. If an object cannot be reached from one of these root objects, it is declared garbage and its memory space is reclaimed. Searching all objects has always been expensive. About twenty years ago the idea of generational garbage collection was introduced.

Generational GC takes advantage of the fact that most objects die young. That is, most objects are only in use for a short amount of time, a string buffer, for example. In generational GC, a section of memory is set aside where new objects are created. After this space is filled, the objects are copied to another section of memory. Each of these sections is referred to as a generation. The HotSpot VM keeps track of these objects so that it can find the connections back to the root objects when GC occurs.

When a GC is run, objects still in use may move up to a more tenured generation. Most generations have their own strategy for culling out objects no longer in use without having to search through all of the memory space. The oldest generation, however, has no such strategy. This default scenario is shown in Figure 1 .

One problem with this is that when garbage collection is run on the permanent generation it takes a while to go through all of that memory space. Moreover, over the course of time, multiple application instances will end up with many of the same objects in their respective permanent generation. If a user is running multiple Java applications, then the permanent generation of one often has the same resources as another which results in wasted memory. Figure 2 illustrates the duplication of resources.

More information on the Java HotSpot VM garbage collection is available online in Sun’s Technical White Paper, The Java HotSpot Virtual Machine, v1.4.1 available at http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_1.html and in Tuning Garbage Collection with the 1.3.1 Java™ Virtual Machine available at http://java.sun.com/docs/hotspot/gc/index.html .

The Advantages of the Java Shared Archive

To get around the problem of wasted memory in the permanent generation, Apple implements a Java Shared Archive technology. This technology is similar to the concept of a shared library in C-based languages. Instead of each Java application needing to keep a separate copy of resources that usually end up in the permanent generation, they are able to share a single copy of these resources which adds a new immortal generation. There are some distinctions between this immortal generation and the other generations:

• Resources are explicitly placed there, they are not promoted to that generation.

• It is never garbage collected.

• A single immortal generation is shared by multiple applications.

When Mac OS X starts up, the Java VM starts in a special mode to build (or update) an archive of resources that would likely end up in the Permanent generation.

After this archive file has been appropriately assembled, the VM shuts down until the user runs a Java application. When a user starts a Java application, the VM can bootstrap off of those resources already on disk, mapping them into the same memory space as the Java heap. Using the archive file speeds up application launch time.

Shorter launch time is a benefit for a single Java application running in Mac OS X. When multiple applications are running, a shared archive also uses less memory. Subsequent applications do not need to allocate space for the resources in the Java Shared Archive; the space has already been allocated on disk. They just need to map to it. As Figure 3 shows, the result is similar to a shared library. The permanent generation tends to be smaller since many of the objects that would be in the permanent generation are available in the Immortal generation.

Apple’s Java Shared Archive implementation in Mac OS X is fully compatible with the Java HotSpot specification and has been presented to Sun for further use within Java.

In summary, the VM uses the generational heap to allocate internal data structures used to implement Java classes. These classes don’t change over time and don’t ever need to be garbage collected. The Mac OS X Java VM extends HotSpot’s notion of generations to include a new generation for these immortal objects. Along with memory savings, time is also conserved since this generation never needs to be searched for dead objects.

---