Garbage Collectors in JVM

Throughput	The percentage of total time not spent in garbage collection, considered over long periods of time.
Garbage collection overhead	The inverse of throughput, that is, the percentage of total time spent in garbage collection.
Pause time	The length of time during which application execution is stopped while garbage collection is occurring.
Frequency of collection	How often collection occurs, relative to application execution.
Footprint	A measure of size, such as heap size.
Promptness	The time between when an object becomes garbage and when the memory becomes available.

Heap is divided into generations, mostly in two

1. young objects
2. old objects

Different collection algorithm can be used for different part (generation) of heap, and each algorithm can be optimized based on commonly observed characteristic of that particular generation.

weak-generation-hypothesis: most objects die young

compare-and-swap

compare-and-swap (CAS) addresses the problem of implementing atomic read-modify-write sequence without locking.

64-bit types and atomicity

Some implementation may find this convenient to divide a single write action onto a 64-bit long or double value into two write action on adjacent 32-bit values. For efficient sake, this behavior is implementation specific

JVM’s are free to perform write to long and double values atomically or in 2 parts. From Java Memory Model point of view a single write to a non-volatile long or double value is treated as two separate write: one for each 32-bits half. This can result into situation where threads see the first 32-bits of a 64-bit value from one write and the second 32-bit from another write.

• Write to a volatile long and double values are always atomic.
• Write to and read of a reference are always atomic; regardless of whether they are implemented as 32-bit or 64-bit

declare shared 64-bit values as volatile or synchronize their read/write.

Further reading

1. 17.7 Non-atomic Treatment of double and long

using volatile variables

Locks offer two primary features:
1. mutual exclusion, and
2. visibility

Mutual exclusion means that only one thread at a time may hold a given lock, and this property can be used to implement protocols for coordinating access to shared data such that only one thread at a time will be using the shared data.

Visibility is more subtle and has to do with ensuring that changes made to shared data prior to releasing a lock are made visible to another thread that subsequently acquires that lock — without the visibility guarantees provided by synchronization, threads could see stale or inconsistent values for shared variables.

Volatile variables share the visibility features of synchronized, but none of the atomicity features. This means that threads will automatically see the most up-to-date value for volatile variables. They can be used to provide thread safety, but only in a very restricted set of cases: those that do not impose constraints between multiple variables or between a variable’s current value and its future values.

Lazy initialization

Lazy initialization holder class idiom for static fields
Utilize JVM’s lazy class loading to create a lazy initialization technique that doesn’t require synchronization on the common code path.

public class ResourceFactory {
 private static class ResourceHolder {
  public static Resource resource=new Resource();
}
public static Resource getResource(){
 return ResourceHolder.resource;
}
}

JVM defers initializing the ResourceHolder class until it is actually used [1] and because Resource is initialized with a static initializer, no additional synchronization is required. The first call to getResource by any thread causes ResourceHolder to be loaded and initialized, at which time the initialization of the Resource happens through static initializer. A modern VM will synchronize field access only to initialize the class. Once the class is initialized, the VM will patch the code so that subsequent access to the field does not involve any testing or synchronization.