JDK-8140483 : Atomic*FieldUpdaters final fields should be trusted
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-10-26
  • Updated: 2019-11-08
  • Resolved: 2015-10-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u101Fixed 9 b92Fixed
Related Reports
Relates :  
Relates :  
Relates :  
The usual pattern for using Atomic*FieldUpdaters is as follows:

public class Data {
    volatile int dataInt;
    static final AtomicIntegerFieldUpdater<Data> UPDATER_INT
            = AtomicIntegerFieldUpdater.newUpdater(Data.class, "dataInt");

    int m() {
        return UPDATER_INT.get(this);

This code will lose against the plain field access and Unsafe access, because updaters do the extensive checks before doing the actual access:

        private final Class<T> tclass;
        private final Class<?> cclass;

        public final int get(T obj) {
            if (obj == null || obj.getClass() != tclass || cclass != null) fullCheck(obj);
            return unsafe.getIntVolatile(obj, offset);

Fortunately, since the use pattern makes the updater a (static final) constant, we can make VM to trust the final instance fields in updater. Then, updater checks would be folded in as constants, closing the gap in updater performance. This is a special case of more general approach (see JDK-8058164), but it seems doable before a more generic solution arrives. This caters for lots of existing users.

Proof-of-concept change:


Quick runs show the entire slab of tests is folded into the typecheck + implicit NP check, with good performance improvements:

RFC: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-October/019528.html