How to decompile volatile variable in Java?

Question

I have been told that the volatile keyword could add memory barrier before write operation of the variable. So i write the code:

public class Test {
    private Object o;

    public Test() {
        this.o = new Object();
    }

    private volatile static Test t;

    public static void createInstance() {
        t = new Test();             // volatile would insert memory barrier here.
    }

    public static void main(String[] args) throws Exception {
        Test.createInstance();
    }
}

And then decompile it:

Compiled from "Test.java"
public class Test extends java.lang.Object{
public Test();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   new #2; //class java/lang/Object
   8:   dup
   9:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   12:  putfield    #3; //Field o:Ljava/lang/Object;
   15:  return

public static void createInstance();
  Code:
   0:   new #4; //class Test
   3:   dup
   4:   invokespecial   #5; //Method "<init>":()V
   7:   putstatic   #6; //Field t:LTest;
   10:  return

public static void main(java.lang.String[])   throws java.lang.Exception;
  Code:
   0:   invokestatic    #7; //Method createInstance:()V
   3:   return

}

I can't see anything related to memory barrier, and then i remove the volatile and decompile it again, the byte code doesn't change at all.

How could i find anything in byte code ?

Answer 1

The concept of memory barrier doesn't exist at the level of Java specification. It is a low-level implementation detail of certain CPU architectures, such as the NUMA architecture which is the most popular today.

Therefore you would need to look at the machine code produced by a Just-in-Time compiler inside a specific JVM implementation, such as HotSpot on an x86 architecture. There, if you are skilled enough to interpret x86 machine code, you would see the manifestation of the memory barrier.

Answer 2

If you test it with javap and the right options, the flag ACC_VOLATILE is visible:

javap  -v -p Test

print:

 private static volatile Test t;
 flags: ACC_PRIVATE, ACC_STATIC, ACC_VOLATILE

(flags are defined in the jvm spec Chapter 4. The class File Format )

Answer 3

Adding volatile to the field does not change Java bytecode that reads or writes the field. It only changes the interpretation of the program by JVM or JIT compilation output if needed. It also influences optimizations.

Field flags

Read and Write synchronization