Happens-before rules in Java Memory Model

I am currently studying for a concurrent programming exam and don't understand why the output of this program is 43. Why is x = y + 1 executed before t.start()? I also should explain which happens-before rules I used.

If I understand the program order rule (each action in a thread happens-before every action in that thread that comes later in the program order) t.start() has to be executed before x = y + 1 so that thread t copies variable x which will be 1.

public class HappensBefore {

static int x = 0;
static int y = 42;

public static void main(String[] args) {
    x = 1;
    Thread t = new Thread() {
        public void run() {
            y = x;
            System.out.println(y);
        };
    };
    t.start();
    x = y + 1;
}

According to JMM:

A call to start() on a thread happens-before any actions in the started thread.

and

If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).

Definition of program order is this:

Among all the inter-thread actions performed by each thread t, the program order of t is a total order that reflects the order in which these actions would be performed according to the intra-thread semantics of t.

The inter-thread semantic is well defined concept in JMM. It means that the order of instructions in a program performed by each thread must be preserved as it is written in the program text.

Applying all these to your case:

t.start(); hb x = y + 1; //program order

t.start(); hb y = x; // happens-before rule specified here

Without additional synchronization we cannot say how x = y + 1; and y = x; relates to each other (From JMM standpoint).

If you are trying to answer the question "What can happen at runtime in my case?". Can happen lots of things... Take a look at this asnwer. Runtime can perform non-trivial optimisations which are consitent with JMM.

Anyway if you are interested about internals you can take a look at this article (Memory Barriers Can Be Avoided). As you can see in the generated assembly, no memory barrier is applied when performing volatile read. I mean that runtime can optimize in anyway... As long the JMM rules are preserved...