Johan Sjölén's blog

Value Classes Still Need Compiler Sympathy

Fri, 21 Aug 2026 00:00:00 +0000

This post discusses preview features in JDK 28

JEP 401, a major Valhalla milestone, has been integrated as a preview feature in JDK 28. This is very exciting, as value classes increase both our ability to communicate the semantics of our programs to others and the optimization opportunities available to the JVM.

However, I have seen people online essentially taking a “Value all the classes!” approach to this. I worry that there is a belief that ordinary classes give you a floor on performance, and that value classes will do their best to raise you above that floor, but won’t ever take you below it. Unfortunately, that is not true. A well-intentioned program may put the JVM into a situation where a flattened representation is faster for some methods, and a reference representation is faster for others. When these methods interact, the JVM is forced to convert between the two representations. I want value classes to be more than just magic, so today I am going to show you what the JVM is capable of right now, and where its limitations are. I hope that with this you’ll have some context for reasoning about the code that you (or your AI agent) write.

The main optimization advantage of value classes is that we give up identity. This gives the JVM freedom to choose a suitable representation for a particular situation. Without the requirement of identity, the runtime can more readily flatten values (avoiding pointer chasing), scalarize them by representing their components independently in registers or on the stack. For the value object itself, escape analysis becomes trivial: there is no identity whose escape must be proven unobservable.

We are going to examine three examples: a large final value stored flat, a direct value transformation compiled without allocation, and a generic virtual call that requires materialization.

Immutability enables flattening

JEP 539, Strict Field Initialization in the JVM, lets the JVM rely on a final field having been initialized before its enclosing object becomes observable. Because such a field cannot later be updated, the JVM may use a non-atomic flattened layout without risking a torn assignment. Mutable fields, however, must preserve tear-free assignment. If a mutable field contains a value that is too large for an atomic flattened update, the JVM must instead use a reference layout. The strict-initialization guarantee opens up many optimization possibilities.

Consider this small example:

value record FourLongs(long a, long b, long c, long d) {}

record Envelope(FourLongs payload) {}

FourLongs has 32 bytes of payload, making it too large for an atomic flattened update in the current JVM. But Envelope.payload is a record component and therefore a strictly initialized final field: once initialized, it is never updated. The JVM is consequently free to store payload using a non-atomic flattened layout. In the current Valhalla master build, the field-layout diagnostic reports the following when using PrintFieldLayout:

Layout of class FourLongs
  @8  REGULAR 8/8 "a" J
  @16 REGULAR 8/8 "b" J
  @24 REGULAR 8/8 "c" J
  @32 REGULAR 8/8 "d" J
  @40 NULL_MARKER 1/1
  NULLABLE_NON_ATOMIC_FLAT layout: 33/8

Layout of class Envelope
  @8 FLAT 33/8 "payload" LFourLongs;
      FourLongs NULLABLE_NON_ATOMIC_FLAT

Here we can see that a FourLongs consists of its four components and a 1-byte null marker, and that it supports a nullable, non-atomic flattened layout. The runtime uses this fact in the Envelope record, and allows FourLongs to be flattened. The key point is that Envelope is also immutable; the layout would have to change if we replaced it with a mutable class:

class MutableEnvelope {
    public FourLongs payload;
   public MutableEnvelope(FourLongs payload) { this.payload = payload; }
}

Layout of class MutableEnvelope
  @8 REGULAR 4/4 "payload" LFourLongs;

Why is that? Let’s consider a data race between two threads:

void thread1(MutableEnvelope a) {
    a.payload = new FourLongs(1, 0, 0, 0);
}

void thread2(MutableEnvelope a) {
    a.payload = new FourLongs(0, 1, 0, 0);
}

void main() throws InterruptedException {
    MutableEnvelope a = new MutableEnvelope(new FourLongs(0, 0, 0, 0));
    var t1 = new Thread(() -> thread1(a));
    var t2 = new Thread(() -> thread2(a));

    t1.start();
    t2.start();

    t1.join();
    t2.join();

    IO.println(a.payload);
}

Writing a flattened field requires writing its individual components. If thread1 and thread2 wrote those components independently, another thread could observe a torn value such as (1, 1, 0, 0), assembled from parts of two different assignments. The Java Memory Model forbids such tearing: after both threads have joined, this program may print only (1, 0, 0, 0) or (0, 1, 0, 0). Guaranteeing tear-free assignment for a flattened value this large would be expensive, so the current JVM uses a reference layout. Each thread constructs a complete FourLongs and then performs an atomic reference store.

Removing identity removes the allocation

If we have a small function that changes a component in a loop, like this:

static FourLongs bumpA(FourLongs value) {
    return new FourLongs(value.a() + 1, value.b(), value.c(), value.d());
}

static long run(long iterations) {
    FourLongs value = new FourLongs(0, 2, 3, 4);
    for (long i = 0; i < iterations; i++) {
        value = bumpA(value);
    }
    return value.a() + value.b() + value.c() + value.d();
}

At the source level, we can see that every call to bumpA constructs a new FourLongs. At the call site of run, however, we can see that the returned value is effectively only there to change the a component of value. A good optimizing compiler ought to be able to recognize that as well. It turns out that C2 is a pretty good compiler! C2 keeps the representation scalarized, and it even recognizes that the final result must be iterations + (2 + 3 + 4) = iterations + 9 when iterations >= 0. The following is an abridged excerpt of the generated code:

mov     x0, #9               ; Put 9 into x0, which holds the return value
cmp     x1, #0               ; Compare x1 (contains iterations) with 0
b.le    done                 ; If less or equal to 0, jump to done
add     x0, x0, w1, sxtw     ; Set x0 = x0 + w1, sign-extending w1 to 64 bits
done:
ret

If we keep bumpA unchanged but make FourLongs an identity record, C2 must prove that its identity has no impact on the computation. Compilers can often do this, but now we depend on the compiler proving it in each case. When I tried to do this (by removing value from the FourLongs declaration), C2 was not capable of performing this optimization.

The following is an abridged excerpt of C2’s compilation of IdentityRecordExperiment::run. The allocation remains in run’s loop even though bumpA has been inlined:

# {method} static 'run' '(J)J' in 'IdentityRecordExperiment'
; initial FourLongs allocation
ldr     x0,  [x28, #TLAB_TOP]
ldr     x10, [x28, #TLAB_END]
add     x11, x0, #0x28          ; reserve 40 bytes
cmp     x11, x10
b.hs    slow_allocation
; object-header setup omitted
str     x11, [x28, #TLAB_TOP]   ; commit allocation
; object initialization omitted

; loop body: allocation from inlined bumpA
ldr     x0,  [x28, #TLAB_TOP]
ldr     x10, [x28, #TLAB_END]
add     x11, x0, #0x28          ; reserve another 40 bytes
cmp     x11, x10
b.hs    slow_allocation
; object-header setup omitted
str     x11, [x28, #TLAB_TOP]   ; commit allocation
; object initialization omitted

Clearly, providing the compiler with stronger semantic guarantees can sometimes produce a very big win.

Type erasure brings the allocation back

Now we are going to look at something a bit more complex. This example is derived from an email we received from a user on the valhalla-dev mailing list. He had ported a parsing library from Elm to Java and noticed a slowdown after converting all of his records to value records. A performance regression is obviously not the result we want, but an unexpected result like this is fascinating: value classes give the JVM more semantic information and greater freedom, so how could using them make the program slower? I did a deep dive to find the cause and a source-level fix. This investigation has opened up an interesting compiler problem that my colleagues on the C2 team are now actively investigating. I’ll explain my findings here, but please keep in mind that I’ve had to simplify this greatly. The JVM and javac are both fairly complex, so I have to leave out details.

value record LargeValue(long a, long b, long c, long d) {}
value record Carrier(LargeValue v, boolean b) {}

interface Fun<R, F> {
    R apply(F value);
}

interface Frobber extends Fun<Carrier, LargeValue> {}

final class FrobIt implements Frobber {
    public Carrier apply(LargeValue value) {
        return new Carrier(value, true);
    }
}

final class GrobIt implements Frobber { /* impl omitted on purpose */ }
final class DrobIt implements Frobber { /* impl omitted on purpose */ }

This is pretty simple code. We have multiple Frobbers that take a LargeValue and produce a Carrier, which contains another LargeValue. The Frobber interface extends the Fun<R, F> interface.

Let’s look at this through the lens of the JVM so that we can understand what is happening. Java implements generics through type erasure, replacing these type parameters with Object. That means that Frobber effectively inherits this method as far as the JVM is concerned:

interface Frobber extends Fun {
    Object apply(Object value);
}

The typed signature Carrier apply(LargeValue) does not appear in the inherited JVM method descriptor and therefore has to be recovered through dynamic analysis. To accommodate this type discrepancy, javac generates bridge methods in the class file. Each implementation gains a method approximately equivalent to this:

// Generated by javac
public Object apply(Object value) {
    return apply((LargeValue) value);
}

The bridge accepts the erased argument, casts it to the expected type, and invokes the method we actually wrote. Now consider the method from the original reproducer:

static Carrier reproduce(LargeValue value, Frobber a, Frobber b) {
    Carrier c = a.apply(value);
    return b.apply(c.v());
}

There are two separate interface call sites here. If each call site only observes one implementation, C2 can devirtualize it. For example, the first call site might always receive a FrobIt, while the second always receives a GrobIt. C2 can independently guard and inline both targets. In this experiment, C2 managed to remove all heap allocations. In pseudo-Java, the result looks like this. We represent scalarized values (values that are not heap references) by appending Fields to the type name:

static CarrierFields reproduce(
        LargeValueFields value,
        Frobber a,
        Frobber b) {

    guard(classOf(a) == FrobIt.class);
    CarrierFields c = inline(FrobIt_apply(value));

    guard(classOf(b) == GrobIt.class);
    return inline(GrobIt_apply(c.v));
}

At this level, there is no longer a call to the generated bridge. Devirtualizing and inlining the target also inlines its bridge. Once the bridge has disappeared into the surrounding compilation, there is no longer a real Object apply(Object) call boundary.

In the report we received, however, the call sites were megamorphic. In our example, that means FrobIt, GrobIt, and DrobIt were all called interchangeably. With three hot implementations at each call site, C2 leaves the calls dynamically dispatched:

invokeinterface Frobber.apply:(Object)Object

The inherited method descriptor defines an ABI that requires callers to pass object references and implementations to return object references.

The caller currently has a scalarized LargeValue, but Object apply(Object) cannot accept four independent scalar components. It requires a genuine reference. The caller must therefore materialize the value before making the call.

The dynamically selected bridge then has to translate in the other direction:

Object FrobIt_apply_bridge(Object argument) {
    LargeValueFields value =
            scalarize((LargeValue) argument);

    CarrierFields result =
            FrobIt_apply_typed(value);

    return materializeCarrier(result);
}

The bridge casts the incoming reference to LargeValue, extracts its components, and invokes the typed implementation using the scalarized value-object calling convention. The typed implementation returns a scalarized Carrier, but the bridge itself promises to return Object, so it must materialize the result before returning.

The megamorphic version of reproduce therefore looks approximately like this:

static CarrierFields reproduce(
        LargeValueFields value,
        Frobber a,
        Frobber b) {

    LargeValue argument1 = materializeLargeValue(value);

    Object returned1 =
            invokeinterface_apply_Object(a, argument1);

    Carrier carrier1 = (Carrier) returned1;
    CarrierFields c = scalarize(carrier1);

    LargeValue argument2 =
            materializeLargeValue(c.v);

    Object returned2 =
            invokeinterface_apply_Object(b, argument2);

    Carrier carrier2 = (Carrier) returned2;
    return scalarize(carrier2);
}

The bridge is acting as an ABI adapter. On one side is the erased Object apply(Object) calling convention. On the other is the typed Carrier apply(LargeValue) calling convention, where value components can be passed and returned in scalarized form.

As you can imagine, this is very expensive. At each call, the caller has to turn a scalarized value into an object reference, which means materializing the value on the heap. It cannot simply point the callee at temporary stack storage: the call is opaque, so the callee may retain the reference and access it after the caller returns. The argument must therefore be a GC-managed heap object.

Luckily, the fix is very simple! We avoid this by explicitly redeclaring the typed method in Frobber:

interface Frobber extends Fun<Carrier, LargeValue> {
    @Override
    Carrier apply(LargeValue value);
}

The @Override annotation documents what we are doing, but the important part is the explicit method declaration. Calls whose static receiver type is Frobber now use the typed descriptor directly:

invokeinterface Frobber.apply:(LargeValue)Carrier

The call is still megamorphic. C2 still does not know whether it will dispatch to FrobIt, GrobIt, or DrobIt. But it no longer needs that knowledge to choose the correct calling convention. Every possible target accepts a LargeValue and returns a Carrier, so the values can cross the dynamic call boundary in scalarized form:

static CarrierFields reproduce(
        LargeValueFields value,
        Frobber a,
        Frobber b) {

    CarrierFields c =
            invokeinterface_typed_apply(a, value);

    return invokeinterface_typed_apply(b, c.v);
}

In the reproducer, the erased megamorphic version allocated 192 bytes per invocation of reproduce. Explicitly redeclaring the typed method reduced that to zero.

Conclusion

Declaring a value class is first and foremost a semantic decision. It tells our fellow programmers that its instances are defined entirely by their state and do not need identity. That clearer model is valuable in itself! The JVM’s additional freedom to optimize how those values are represented is a welcome bonus.

C2 can do amazing things with that freedom, but it cannot always recover information hidden behind abstraction boundaries. Profiling and inspecting the generated code remain the best ways to understand what is happening.

To get the best results, we may still need to have a little sympathy for the compiler.

Appendix: printing C2 assembly

If you want to double-check my work, you can take these code snippets and inspect the assembly yourself. Compile with preview enabled, make sure the target method is invoked often enough to become hot, and then ask the VM to compile and print it:

javac --enable-preview --release 28 Example.java
java --enable-preview -Xbatch -XX:-TieredCompilation \
  -XX:+UnlockDiagnosticVMOptions \
  -XX:CompileCommand=compileonly,Example::method \
  -XX:CompileCommand=print,Example::method \
  -XX:+PrintAssembly Example

-Xbatch makes compilation synchronous, and compileonly keeps the output focused. Note that compileonly restricts which methods may be compiled; it does not trigger compilation. Example::method must still be invoked enough times to reach the compilation threshold. Printing assembly requires a JVM build with a disassembler available. Omit --enable-preview when compiling and running the ordinary-record comparison.

You should be using Async UL when collecting GC logs!

Tue, 23 Jun 2026 00:00:00 +0000

TL;DR:

If you are on a modern JDK (25 or newer) and perform GC log analysis, you probably want to add this startup argument:

-Xlog:async:stall

It will make all GC logging asynchronous, while guaranteeing that no messages will be dropped. The older mode, which was accessed with -Xlog:async, could potentially drop messages. This mode will instead stall producer threads to allow the output thread to catch up.

Use -XX:AsyncLogBufferSize=N to change the buffer size, an increased buffer size helps with temporary hiccups in output speed. A complete invocation could look something like this:

java -XX:AsyncLogBufferSize=8M -Xlog:async:stall -Xlog:gc*:file=gc-%p-%t.log:uptime,level,tags:filecount=5,filesize=20M

Run java -Xlog:help for more information.

Background

GC logs are one of those things that have become standard to enable for your Java application. You turn them on, forget about them, and then one day they are the only thing standing between you and a very annoying afternoon.

Unfortunately, collecting logs is not free. The VM has to write the messages somewhere, and that work has to happen at some point. Under the default Unified Logging system (the machinery powering all VM logs, including GC), printing log messages is a fully synchronous process: The producer thread, meaning the thread that produces a log message, is also the one that outputs it. This can be extremely detrimental to pause times, as your GC must now await the log write to finish before continuing.

In JDK 17, the UL system gained an asynchronous mode. Instead of making the producer thread also do the output work, the VM can enqueue the message and let a separate output thread flush it out.

This is a very nice idea. The GC can go back to doing GC things, and the boring output work can happen somewhere else. In the happy case, this gives us what we want: lower disruption from the logging itself, while still getting the log file we asked for.

Unfortunately, nothing is allowed to be quite that simple.

The buffer used by asynchronous logging is bounded. It has to be, otherwise a sufficiently enthusiastic logging configuration could just turn memory into a sad little text warehouse. So, there is an obvious question: what happens when producer threads create messages faster than the output thread can write them?

Before JDK 25, the answer was that producer threads would drop any messages that there isn’t room for.

This is not a bad answer. If you ask for non-blocking logging, then non-blocking logging is what you get. The VM keeps moving, the application keeps moving, and the output thread can catch up. For some kinds of logging this is a perfectly reasonable trade-off. For GC logs, though, this can be the wrong trade-off.

If I am collecting GC logs, it is usually because I want to analyze them later. Maybe I want to understand latency. Maybe I want to compare collectors. Maybe I want to explain why some service decided to have a dramatic little moment in production. In all of these cases, having a chunk of log messages dropped because your output thread stumbled a bit can have a real impact on your analysis.

I thought that we can do better, so I decided to have a look at how we can alleviate any user’s worries regarding dropping asynchronous messages. I developed a solution which ships in JDK 25. In this release, Unified Logging gained another asynchronous mode. Instead of dropping messages when the buffer is full, it will stall all producer threads until the output thread has caught up.

Now, instead of specifying -Xlog:async you may append a mode to the startup argument, that mode either being :drop or :stall. The new mode is :stall, that’s what you want to add if you don’t want any messages to be dropped. Plain -Xlog:async is still the best-effort version.

This may sound like we have just reinvented synchronous logging with extra steps, but we have not. Most of the time, logging still works asynchronously. The producer thread enqueues the log message and continues. The output thread handles the slow part. The stalling only matters when the buffer fills up, which is exactly the moment where the old behavior could silently lose data.

So the trade-off becomes much nicer:

Compared with synchronous logging, most log messages do not have to pay the direct output cost.
Compared with dropping asynchronous logging, the log file remains complete.

This is what we in Sweden call a “lagom” solution. You get lower collection costs in the common case, and when the logging system is under pressure, you preserve the thing you actually wanted: a trustworthy log.

If you already have a GC logging line, keep it. Add the async mode next to it. For example, the important part of the configuration may look like this:

java -Xlog:async:stall -Xlog:gc*:file=gc-%p-%t.log:uptime,level,tags:filecount=5,filesize=20M

This is not only useful on multi-core machines. On a single-core system, asynchronous logging can still be a sensible arrangement. Since the output thread can sleep while waiting for a piece of output to be written to file, it will yield and the application threads can continue doing useful work.

Implementation overview

The asynchronous logging implementation uses a ping-pong buffer design. There are two fixed-size buffers: one active buffer used by producer threads, and one flushing buffer used by the output thread from which messages are taken and written to output devices.

At a high level, the normal flow looks like this:

producer threads
   | push log message
   | signal: data available
   v
+-------------+       output thread wakes
| active      |---------------------------+
| buffer      |                           |
+-------------+                           |
      ^                                   |
      | output thread swaps buffers <-----+
      v                                   |
+-------------+                           v
| flushing    | ----> output thread writes to output devices --->
| buffer      |
+-------------+

When a producer thread emits a log message, it takes a lock, appends the message to the active buffer, signals that data is available, and then continues. The output thread waits for that signal. Once there is work to do, it takes the lock, swaps the active and staging buffers, and releases the lock again. The output thread competes with the producer threads for the lock. We could have been more clever here, but we’ve found that in practice there is no starvation, and this let’s the buffer be filled with more than just one message before the output thread claims the locks.

After the swap, the output thread writes the contents of the staging buffer. This is the central point of the design: the lock is held while buffers are exchanged, but not while log output is written. Producer threads therefore avoid waiting for the ordinary I/O path in the common case.

In stall mode, a full active buffer is handled differently from the original dropping mode. If a message does not fit, the producer thread creates a temporary message area sized for that message, posts it for the output thread, and waits until it has been written. This prevents all other producer threads from progressing as well.

active buffer full

producer thread -> [ one-off waiting message ] ---> output thread
       ^                                            |
       |                                            v
       +-------------- wake after write <-----------+

The output thread writes the ordinary buffer first, then writes the waiting message, and finally wakes the stalled producer thread. The result is that the common case remains asynchronous, while the full-buffer case becomes explicit waiting instead of silent message loss.