A full garbage collection generally expresses the notion of garbage collecting and compacting the old generation and permanent generation spaces. (查看原文)
In the HotSpot VM, the default behavior on a full garbage collection is to garbage collect the young generation, old generation, and permanent generation spaces. (查看原文)
It is possible to configure the HotSpot VM to not garbage collect the young generation space on a full garbage collection prior to garbage collecting the old generation space using the command line option -XX:-ScavengeBeforeFullGC. The "-" character preceding the ScavengeBeforeFullGC disables the garbage collection of the young generation space on a full garbage collection. In contrast, a "+" character in front of ScavengeBeforeFullGC enables the garbage collection of the young generation space on a full garbage collection. (查看原文)
Garbage collecting the young generation space prior to garbage collecting the old generation space usually results in less work for the garbage collector and more objects being garbage collected since objects in the old generation space may be holding object references to objects in the young generation space. If the young generation space is not garbage collected, any object in old generation space that holds a reference to an object in young generation space cannot be garbage collected. (查看原文)
The launcher executes a sequence of operations to start the HotSpot VM. These steps are summarized here:
1. Parse command line options.
Some of the command line options are consumed immediately by the launcher such as -client or -server, which determines the JIT compiler to load. Other command line options are passed to the launched HotSpot VM. (查看原文)
2. Establish the Java heap sizes and the JIT compiler type (client or server) if these options are not explicitly specified on the command line.
If Java heap sizes and JIT compiler are not explicitly specified as a command line option, these are ergonomically established by the launcher. Ergonomic defaults vary depending on the underlying system configuration and operating system. Ergonomic choices made by the HotSpot VM are described in more detail in the “HotSpot VM Adaptive Tuning” section later in this chapter. (查看原文)
5. Create the HotSpot VM using the standard Java Native Interface method JNI_CreateJavaVM in a newly created nonprimordial thread.
In contrast to a nonprimordial thread, a primordial thread is the first thread allocated by an operating system kernel when a new process is launched. Hence, when a HotSpot VM is launched, the primordial thread is the first thread allocated by the operating system kernel running in the newly created HotSpot VM process. Creating the HotSpot VM in a nonprimordial thread provides the ability to customize the HotSpot VM such as changing the stack size on Windows. More details of what happens in the HotSpot VM’s implementation of JNI_CreateJavaVM are provided in the “JNI_CreateJavaVM Details” sidebar. (查看原文)
6. Once the HotSpot VM is created and initialized, the Java Main-Class is loaded and the launcher gets the Java main method’s attributes from the Java Main-Class.
7. The Java main method is invoked in the HotSpot VM using the Java Native Interface method CallStaticVoidMethod passing it the marshaled arguments from the command line. (查看原文)
Class Metadata in HotSpot
Class loading in the HotSpot VM creates an internal representation of a class in either an instanceKlass or an arrayKlass in the HotSpot VM’s permanent generation space. The HotSpot VM’s permanent generation space is described in more detailed in the “HotSpot VM Garbage Collectors” section later in this chapter. The instanceKlass refers to a Java mirror, which is the instance of java.lang.Class mirroring this class. The HotSpot VM internally accesses the instanceKlass using an internal data structure called a klassOop. An “Oop” is an ordinary object pointer. Hence, a klassOop is an internal HotSpot abstraction for a reference, an ordinary object pointer, to a Klass representing or mirroring a Java class. (查看原文)
A C++ JavaThread instance that represents the java.lang.Thread instance internally within the HotSpot VM. It contains additional information to track the state of the thread. A JavaThread holds a reference to its associated java. lang.Thread object, as an ordinary object pointer, and the java.lang.Thread object also stores a reference to its JavaThread as a raw int. A JavaThread also holds a reference to its associated OSThread instance. (查看原文)
A server-class machine in the HotSpot VM is defined as a system with an underlying configuration that has two or more gigabytes of physical memory and two or more virtual processors.
Also note when running a HotSpot VM in an operating system configured with a processor set, the value returned by the Java API Runtime.availableProcessors() is the number of virtual processors observed within the processor set, not the number of virtual processors observed system wide. (查看原文)
It actually performs a full garbage collection when it determines there is not enough available space for object promotions from the next minor garbage collection. This is a less costly approach rather than being in the middle of a minor garbage collection and discovering that the promotion of an object will fail. Recovering from an object promotion failure is an expensive operation. (查看原文)
When examining garbage collection data and observing minor garbage collections that are too lengthy, the corrective action is to reduce the size of the young generation space. If minor garbage collections are too frequent, then the corrective action is to increase the size of the young generation space. (查看原文)
Tip
There is a subtle difference between a stop-the-world compacting garbage collection and a full garbage collection. In CMS, when there is not enough available space in old generation space to handle object promotions from the young generation space, a stop-the-world compacting garbage collection occurs only in the old generation space. When a full garbage collection occurs, both the young generation and old generation space are garbage collected except when -XX:-ScavengeBeforeFullGC is in use. (查看原文)
CMS Pause Time Tuning
...
The remark phase is multithreaded. The number of threads used in the remark phase can be controlled by the following HotSpot VM command line option:
-XX:ParallelGCThreads=<n>
As of Java 6 Update 23, it defaults to the number returned by the Java API Runtime.availableProcessors() if the number returned is less than or equal to 8; otherwise, it defaults to 5/8 the number returned by Runtime.availableProcessors(). (查看原文)
On Oracle Solaris,
the pagesize command with no arguments reports the default page size.
On Linux, the default page size can be obtained using the getconf PAGESIZE
command.
Windows on x86 and x64 platforms default to a 4K (4096) page size. (查看原文)
An additional strategy to reduce system CPU utilization for applications performing
large amounts of network I/O is utilizing Java NIO nonblocking data structures. Java
NIO was introduced in Java 1.4.2 with many runtime performance improvements
added in Java 5 and Java 6. Java NIO nonblocking data structures allow for the ability
to read or write as much data as possible in a single call to a network I/O (read
or write) operation. (查看原文)
