The pc Register#

The _pc (program counter) register is one of the most fundamental of memory areas and operates on a strict per-thread basis.

The Java Virtual Machine can support many threads of execution at once. Each Java Virtual Machine thread has its own pc (program counter) register. At any point, each Java Virtual Machine thread is executing the code of a single method, namely the current method for that thread. When a new thread is created, it is immediately allocated its own pc register. The primary responsibility of this register is to act as a “bookmark”, keeping track of exactly where the thread currently is in its execution sequence.

• If that method is not native, the pc register contains the address of the Java Virtual Machine instruction currently being executed.
• If the method currently being executed by the thread is native (meaning code written in another language like C or C++ that interacts directly with the host operating system), the JVM steps back, i.e. the value of the Java Virtual Machine’s pc register is undefined because the underlying native platform’s program counter takes over the tracking responsibility.

Here is a realistic illustration of how the JVM organizes the pc register across different threads as part of the Run-Time Data Areas.

This diagram demonstrates a few key aspects of the JVM specification:

1. Isolation: Thread 1 and Thread 2 are entirely separate containers with their own registers and stacks.
2. Tracking Java Code: For Thread 1, the PC Register points to a specific bytecode address (invokevirtual in the calculateValue method).
3. Handling Native Code: For Thread 2, which is executing code outside the JVM (a native method), the specifications state that the JVM pc register is undefined

Java Virtual Machine Stacks#

Each Java Virtual Machine thread has a private Java Virtual Machine stack, created at the same time as the thread. JVM Stacks are private to each thread and store frames, which are created with every method invocation and destroyed upon method completion. Each frame is the storage location for local variables (like integers or object references), an operand stack (for expressions), and other data required for method execution. Think of the stack as a record of method calls, and the frames as the internal state of each of those active calls.

Heap#

The Java Virtual Machine has a heap that is shared among all Java Virtual Machine threads. The heap is the run-time data area from which memory for all class instances and arrays is allocated.

The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector); objects are never explicitly deallocated. The Java Virtual Machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor’s system requirements.

Method Area#

The Java Virtual Machine has a method area that is shared among all Java Virtual Machine threads. The method area is analogous to the storage area for compiled code of a conventional language or analogous to the “text” segment in an operating system process. It stores per-class structures such as the run-time constant pool, field and method data, and the code for methods and constructors, including the special methods used in class and interface initialization and in instance initialization.

Run-Time Constant Pool#

A run-time constant pool is a per-class or per-interface run-time representation of the constant_pool table in a class file. It contains several kinds of constants, ranging from numeric literals known at compile-time to method and field references that must be resolved at run-time. The run-time constant pool serves a function similar to that of a symbol table for a conventional programming language, although it contains a wider range of data than a typical symbol table.

Native Method Stacks#

An implementation of the Java Virtual Machine may use conventional stacks, colloquially called “C stacks,” to support native methods (methods written in a language other than the Java programming language). Native method stacks may also be used by the implementation of an interpreter for the Java Virtual Machine’s instruction set in a language such as C. Java Virtual Machine implementations that cannot load native methods and that do not themselves rely on conventional stacks need not supply native method stacks. If supplied, native method stacks are typically allocated per thread when each thread is created.

Serialization Filter Configuration#

JEP 290: Filter Incoming Serialization Data

“Allow incoming streams of object-serialization data to be filtered in order to improve both security and robustness.”

JEP 290 introduced serialization filtering to Java, allowing control over which classes can be deserialized from an ObjectInputStream. As an example, suppose we have 2 serializable classes: AllowedClass and RestrictedClass:

1
package com.example.allowed;
2

3
import java.io.Serial;
4
import java.io.Serializable;
5

6
public class AllowedClass implements Serializable {
7
    @Serial private static final long serialVersionUID = 1L;
8
    public String message;
9

10
    public AllowedClass(String message) {
11
        this.message = message;
12
    }
13

14
    @Override
15
    public String toString() {
16
        return "AllowedClass: " + message;
17
    }
18
}

1
package com.example.restricted;
2

3
import java.io.Serial;
4
import java.io.Serializable;
5

6
public class RestrictedClass implements Serializable {
7
    @Serial private static final long serialVersionUID = 1L;
8
    public String secret;
9

10
    public RestrictedClass(String secret) {
11
        this.secret = secret;
12
    }
13

14
    @Override
15
    public String toString() {
16
        return "RestrictedClass: " + secret;
17
    }
18
}

To make sure AllowedClass can be deserialized while RestrictedClass cannot, we can use either pattern-based filters defined via system properties or security properties, or programmatically using the ObjectInputFilter API.

1
import java.io.ByteArrayInputStream;
2
import java.io.ByteArrayOutputStream;
3
import java.io.IOException;
4
import java.io.ObjectInputStream;
5
import java.io.ObjectOutputStream;
6
import java.io.Serializable;
7

8
public static void serialize(Serializable obj, Class<? extends Serializable> clazz) {
9
    try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)) {
10
        oos.writeObject(obj);
11

12
        try (ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
13
             ObjectInputStream ois = new ObjectInputStream(bis)) {
14
            Serializable result = clazz.cast(ois.readObject());
15
        }
16
    } catch (IOException | ClassNotFoundException exception) {
17
        throw new IllegalStateException(exception);
18
    }
19
}
20

21
AllowedClass allowed = new AllowedClass("Hello Allowed!");
22
RestrictedClass restricted = new RestrictedClass("Secret Data!");
23

24
serialize(allowed, AllowedClass.class);       // ✅
25
serialize(restricted, RestrictedClass.class); // ❌ runtime error

1
import java.io.ByteArrayInputStream;
2
import java.io.ByteArrayOutputStream;
3
import java.io.IOException;
4
import java.io.ObjectInputFilter;
5
import java.io.ObjectInputStream;
6
import java.io.ObjectOutputStream;
7
import java.io.Serializable;
8

9
public static void serialize(Serializable obj, Class<? extends Serializable> clazz) {
10
    try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)) {
11
        oos.writeObject(obj);
12

13
        try (ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
14
             ObjectInputStream ois = new ObjectInputStream(bis)) {
15

16
            ois.setObjectInputFilter(info -> {
17
                if (info.serialClass() != null && info.serialClass().getName().startsWith("com.example.allowed")) {
18
                    return ObjectInputFilter.Status.ALLOWED;
19
                }
20
                return ObjectInputFilter.Status.REJECTED;
21
            });
22

23
            Serializable result = clazz.cast(ois.readObject());
24
        }
25
    } catch (IOException | ClassNotFoundException exception) {
26
        throw new IllegalStateException(exception);
27
    }
28
}
29

30
AllowedClass allowed = new AllowedClass("Hello Allowed!");
31
RestrictedClass restricted = new RestrictedClass("Secret Data!");
32

33
serialize(allowed, AllowedClass.class);       // ✅
34
serialize(restricted, RestrictedClass.class); // ❌ runtime error

Compact Strings#

JEP 254: Compact Strings

“Adopt a more space-efficient internal representation for strings.”

Before compact strings, Java’s String class stored characters in a char[] array, where each char is 2 bytes (UTF-16 encoding). This meant that even strings containing only ASCII characters (which could be represented by 1 byte) would still consume 2 bytes per character.

With JEP 254, the String implementation was changed to use either the old storage mechanism or a byte[] array plus an encoding flag. If the string contains only Latin-1 characters (characters with code points from 0 to 255, fitting within 1 byte), it will be stored as a byte[] array, effectively using 1 byte per character. If it contains characters outside of Latin-1 (requiring more than 1 byte), it will revert to the 2-byte-per-character UTF-16 representation.

The compact string optimization is transparent to the developer. We continue to use the String class as before. The JVM automatically decides the most memory-efficient internal representation based on the characters present in the string. This significantly reduces the memory footprint of applications that deal extensively with ASCII or Latin-1 based strings, which is a very common scenario.

Support Bounding the Size of Buffers Cached in the Per-Thread Buffer Caches#

JDK-8147468

JDK-8147468 is a specific enhancement that was included in OpenJDK 9 to address a potential memory management issue in the Java NIO (Non-blocking I/O) package. It allows developers to set a limit on the size of temporary buffers, preventing a form of memory leak.

Java’s NIO framework uses DirectByteBuffers for certain I/O operations. These are buffers allocated outside the Java heap, in “native memory,” to provide better performance by avoiding an extra copy of data. To optimize performance and reduce the overhead of constant allocation and deallocation, the Java Virtual Machine (JVM) caches these temporary DirectByteBuffers in a per-thread cache.

The core issue that JDK-8147468 addresses is that in older JDK versions (before 8u102 and JDK 9), this cache had no size limit. If an application performed a large, but infrequent, NIO operation that required a very big buffer, this large buffer would then be stored in the thread-local cache. Over time, these caches could accumulate a number of large buffers, leading to excessive native memory consumption, which could ultimately result in a java.lang.OutOfMemoryError even if the Java heap itself had plenty of space. It’s a bit like a person who, while trying to be efficient, ends up hoarding very large, but rarely-used, items in their pockets. Eventually, their pockets get so full and heavy that they can’t move freely.

To solve this, JDK-8147468 introduced a new system property: jdk.nio.maxCachedBufferSize. By setting this property, we can specify a maximum size for any buffer that can be held in the per-thread cache. For example, if we set jdk.nio.maxCachedBufferSize=1048576 (1 MB), any NIO operation that requires a buffer larger than 1 MB will not store that buffer in the cache. Instead, the JVM will simply allocate a new, one-off buffer for the operation and then free it immediately afterward. This prevents the native memory cache from growing indefinitely and mitigates the risk of an OutOfMemoryError due to a native memory leak. This change gives developers greater control over their application’s native memory footprint.

1
RandomAccessFile file = new RandomAccessFile("data.txt", "r");
2
FileChannel fileChannel = file.getChannel();
3
ByteBuffer buffer = ByteBuffer.allocate(512);
4

5
int bytesRead = fileChannel.read(buffer);
6
while (bytesRead != -1) {
7
    buffer.flip();
8

9
    while (buffer.hasRemaining()) {
10
        System.out.print((char) buffer.get());
11
    }
12

13
    buffer.clear();
14
    bytesRead = fileChannel.read(buffer);
15
}
16

17
fileChannel.close();
18
file.close();

A Brief Overview of Caching Algorithms#

There is no single “all” list, as new and hybrid algorithms are constantly being developed, but they all fall into a few key families. These algorithms, known as cache replacement policies, are rules that decide which piece of data to evict (remove) when the cache is full and new data needs to be added.

The goal is always to maximize the cache hit rate (finding the data in the cache) and minimize the cache miss rate (having to fetch the data from slower, underlying storage).

Here is a breakdown of the most important caching algorithms, from simple to advanced.

Caching API in OpenJDK#

OpenJDK’s standard API does not provide built-in, “out-of-the-box” implementations for all of those algorithms. The Java standard library provides the building blocks (like HashMap and LinkedList), but it expects us to either build a cache ourselves or, more commonly, use a dedicated third-party library. The only algorithm we can easily implement with a built-in class, however, is LRU. The java.util.LinkedHashMap class can be configured to function as a simple LRU cache by overriding its removeEldestEntry method:

1
import java.util.LinkedHashMap;
2
import java.util.Map;
3

4
/**
5
 * A cache class with Least Recently Used (LRU) eviction policy.
6
 *
7
 * @param <K>  The type of keys maintained by this cache
8
 * @param <V>  The type of cached values
9
 */
10
public class LruCache<K, V> extends LinkedHashMap<K, V> {
11

12
    private final int cacheSize;
13

14
    /**
15
     * Constructs an empty {@link LruCache} instance with the provided maximum number of entries hold in the cache.
16
     *
17
     * @param cacheSize  Maximum number of entries in cache
18
     */
19
    private LruCache(final int cacheSize) {
20
        super(cacheSize * 4 / 3, 0.75f, true);
21
        this.cacheSize = cacheSize;
22
    }
23

24
    /**
25
     * Creates a new instance of {@link LruCache} with the provided maximum number of entries hold in the cache.
26
     *
27
     * @param cacheSize  Maximum number of entries in cache
28
     *
29
     * @param <K>  The type of keys maintained by this cache
30
     * @param <V>  The type of cached values
31
     *
32
     * @return a new initialized {@link LruCache} instance
33
     */
34
    public static <K, V> LruCache<K, V> ofSize(final int cacheSize) {
35
        return new LruCache<>(cacheSize);
36
    }
37

38
    @Override
39
    protected boolean removeEldestEntry(final Map.Entry<K, V> eldest) {
40
        return size() > getCacheSize();
41
    }
42

43
    private int getCacheSize() {
44
        return cacheSize;
45
    }
46
}

OpenJDK includes the javax.cache API, known as JCache (JSR 107). This is an interface specification, not an implementation. It provides a standard set of methods (CacheManager, Cache, get, put), but we must plug in a caching library (like Caffeine) that actually implements the logic.

For any serious caching, Java developers should use high-performance libraries. Here’s how they map to the algorithms we just listed:

• Google Guava (The Predecessor): Guava’s cache uses a size-based LRU-like policy. It evicts the least recently used items when the cache reaches its maximum size.

• Caffeine (The Modern Standard): This is the high-performance library that replaced Google’s Guava cache. It does not use a simple LRU or LFU. It uses W-TinyLFU, a much more advanced algorithm that provides near-optimal hit rates by combining the best parts of both LFU (frequency) and LRU (recency). It’s highly scan-resistant and generally superior to the simple algorithms.

• Ehcache (The Enterprise Standard):

  • Ehcache 2.x (older) allowed us to explicitly configure LRU, LFU, or FIFO.
  • Ehcache 3.x (current) simplified this. It no longer lets you choose and primarily uses a sampling-based LRU for in-memory caching.