All Fields Are Final

Final fields semantics in JLS is quite sophisticated. It is one of four pieces which comprise the Java Memory Model (others are: values read/write atomicity, happens-before semantics, well-formed executions and commit order). Final field semantics boils down to this:

This semantics offers a great freedom for runtime to cache the final fields as soon it discovers them. The added "benefit" is that final-bearing objects are safely publishable through the data races. Racy publication is still a big NO-NO, but for final fields it is more tolerable.

Since memory models are great compromise about what users can expect, and what we are actually able to pull off, any semantics needs a plausible implementation. One of the conservative implementations is described in Doug’s JSR 133 Cookbook .^[1] Note the Cookbook is not the definition of the Java Memory Model, it just describes the simple set of rules the implementation may follow to match the requirements of JMM.

In short, on writer side it is enough to make sure the stores in the constructor are ordered before the publication of the object holding the field. That requires us to put the barrier between initializing stores and publishing the reference:

JSR 133 Cookbook only requires StoreStore, but might also require LoadStore barriers. This covers for a corner case when the final field value depends on some field (the interesting example if we do the increment of the field itself) which experiences a racy update. This corner case may result in storing the value derived by that racy update, not by constructor itself, and that would obliterate the safe construction guarantees^[2].

Now, these barriers are intents and not the real things. Think about them as the synthetic actions which prevent reordering of relevant operations across the barrier. This action is processed on two levels: runtimes are prohibited from moving ops around that barrier, and also require to communicate this barrier to hardware, if needed. We will see that some hardware requires the explicit barrier, and some hardware does not.

There is a symmetric requirement on reader side: we enforce the order of the reference access, and field access itself:

Breaking this order is not directly possible on runtime side, because it will violate the data dependencies. Note that if we somehow acquired c early, then we can speculate about its value and do the field access early, breaking the visibility of written value of tc.c. Spec specifically allows this behavior, because it means we have the indirection chain to the field access bypassing the freeze action.

Turns out, most hardware also respects the order of so-called 'dependent' reads, and hence does not require emitting the barrier there.

Let’s see how current implementation deals with these two constraints. Since all platforms we target already respect the dependent loads, we only concentrate on writer side. This is the relevant part of HotSpot code which emits the aforementioned barrier if we detect we have written out the final field:

This code is the part of machinery parsing the incoming bytecode into the High-level Internal Representation (HIR, or IR). This membar materializes (or not) in the machine code, when emitter produces the machine code. It may be confusing the code appears to add MemBarRelease, but fear you not, it is actually the LoadStore|StoreStore, which makes it a release fence: no operations can float down the succeeding store.

Now, what these barriers look like on different platforms? In all cases, runtime still needs to preserve the order in the generated machine code, so there the barrier effect even if hardware does not require anything else. As far as hardware is concerned, JSR 133 Cookbook sums up the hardware specs:

These differences on hardware level complicate the performance model around finals, and make our investigation job harder.

Now that we made the required introductions, it is interesting to estimate the actual cost of maintaining the final field semantics. Since this semantics is arguably usable for safe initialization even for mutable non-final objects, it poses the question: "What would be the costs of requiring the final-like semantics for all the objects in an application?"

It all sounds simple so far, right? Especially knowing where exactly the barriers for final fields are in HotSpot. Hack it up, run some benchmarks, and conclude the result. This is a wrong way to start: you first need to understand what you are dealing with. In that spirit, let’s construct the simple benchmark first. This benchmark has some interesting traits:

This is the part on benchmarking quirks, and the importance of experimental control. You can skip this part right to the ARM section below.

This is the final chart we have got for our ARM host (raw data):

Some quick observations:

To double-check the results, let’s see the disassembled code for plain/minus in -server mode (we had cleaned up unnecessary bloat, contrasted the instance allocation path, and made a few comments).^[5]

There is a final StoreStore, and it looks like the final fields barrier. It is not, this is the object metadata barrier, which guards the values written out in the object header. It had floated all the way down before the object is published. This is a legal transformation, even though it appears as if the stores floated before the barrier: the memory effects in the IR are projected from AllocateNode to the first use, which allowed us to move the barrier down to the escape point.

The same example, but for the final fields, final/minus and -server: ^[5]

The same assembly is produced for final/plus and plain/plus, hooray! The performance difference is because of the excess LoadStore|StoreStore, this is our barrier emitted from MemBar_Release. The important and interesting thing to see here is that both barriers are going back-to-back, which opens up the simple way of peephole-ing both into single (StoreStore + LoadStore|StoreStore) ⇒ LoadStore|StoreStore. Which means the object header barrier can piggyback on final release barrier. We recorded this observation as JDK-8032481.

Things get interesting in -client mode. With plain/minus, we get: ^[5]

The metadata StoreStore barrier is right after object was blankly-initialized. C1 IR is not sophisticated enough to track the memory projections, and hence the barrier sits right there we put it. For final/plus and -client you might notice the slight difference:^[5]

There is a trailing StoreStore barrier, like the one we emitted in our patch. This is the "final fields" barrier, and the assembly is the same in final/plus and plain/plus modes. You might notice -client is only emitting StoreStore though. This is a gray area for JMM at this point, and both behaviors are arguably legal.

This is the final chart we got for x86 (raw data):

Observations:

Just to be on the safe side, let us peek into the assembly. This generated code is identical in all modes:

No barriers, no fuzz.

This is the final chart we got for PowerPC (raw data):

Confirming this with disassembly, plain/minus first: ^[5]

It is coherent with ARM C1 disassembly: we have the object metadata header guarded by the barrier, and then the naked field stores. The same thing, but for final/minus (plain/plus and final/plus yield the same code): ^[5]

Here, we have an additional trailing barrier after the field stores. This is our MemBarRelease lowered to lwsync. Note that we could also coalesce these barriers, but it requires more advanced coalescing logic in HotSpot.

Now that we know the barriers are properly emitted, and also managed to get the basic performance estimates, we can explore the quality of implementation issues a little bit closer. Since we already know the barriers are emitted at the end of constructor in the bytecode parser, it seems educational to stress that part. We can do that by ramping up another targeted benchmark.

The highlights of that benchmark are:

This section is short, because the control procedures and validation sequence is similar to the first experiment. We did it, but skip the details here.

On x86, all tests are behaving similarly (raw data here), as we would expect in the absence of any hardware memory barriers. Compiler barriers are not affecting the performance.

On weakly-ordered architectures like PowerPC, it starts to get interesting (raw data here):

This effect is getting even more concise on ARMs (raw data here):

This experiment outlines it is important to do barrier coalescing. We recorded this experiment in JDK-8032218.

Observations (raw data here):

Observations (raw data here):

Observations (raw data here):