What kind of optimalization JIT applied to while loop

Question

I wrote down this code:

public class Main {

    private boolean stopThread = false;
    private int counter = 0;

    public static void main(String[] args) throws InterruptedException {
        final Main main = new Main();

        new Thread(() -> {
            try {
                System.out.println("Start");
                Thread.sleep(100);
                System.out.println("Done");
                main.stopThread = true;
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

        }).start();

        new Thread(() -> {
            while (!main.stopThread) {
                main.counter++;
            }
            System.out.println(main.counter);
        }).start();
        System.out.println("End");
    }
}

and when I run it, the while loop will be running on forever. I was struggling with this a bit, and I got confused what kind of optimalization JIT applied to this code.

First of I was thinking that this is a problem with visibility of stopThread variable, but even if it is a true the while loop should stop a little bit later than I assigned stopThread to true (when CPU cache from 1st thread got flushed to the main memory), so it cannot be the case. It looks like the JIT hardcoded false to stopThread variable, and if it is true, why this variable is not refreshed periodically somehow on runtime?

Obviously, the volatile keyword fixed that, but it is not answering me to that question because volatile can ensures visibility as well as prevent JIT from number of optimalizations.

Even more, when I change the sleep time to 1ms, the second thread will terminate properly, so I'm pretty sure that this is not about variable visibility.

UPDATE: It is worth to mention that I'm getting non-zero value from the counter when the sleep time is set to 1-10 ms.

UPDATE 2: Additionaly, I can say that -XX:+PrintCompilation shows that in case when the sleep time is set to 100 ms the while loop gets compiled, and the On Stack Replacement happend.

UPDATE 3: Probably this is what I was looking for: https://www.youtube.com/watch?v=ADxUsCkWdbE&feature=youtu.be&t=889. And as I thought - this is one of "optimalization" performed by JIT, and the way to prevent it is to specify variable as volatile, or put loadloadFence as the first line in while loop.

ANSWER: As @apangin said:

This optimization is Loop invariant hoisting. JIT is allowed to move the load of stopThread out of the loop, since it may assume that non-volatile field does not change externally, and JIT also sees that stopThread does not change inside the loop.

Answer 1

The reason isn't JIT optimization. Your code is doing unsynchronized access to a shared variable, stopThread (let's call it "flag").

Essentially there is a race condition between the thread that is setting the flag to a truthy value and the other thread that is checking the value. If the flag is set true before the loop is entered, the code completes. If not (race lost), the loop will continue indeterminately long, because the CPU cache holds the falsey value. When the flag is volatile, its value is read from main memory instead of the CPU cache and the loop eventually finishes right after the flag-setting thread is done with sleeping.

Answer 2

I think you are coming at this problem from the wrong direction.

What you have is a program with an unspecified behavior with respect to memory visibility. If two threads are reading and writing a shared variable, it must be done in specific ways to guarantee that one thread sees th other threads writes. You need to use synchronized or a volatile variable to ensure that the write happens before the read.

If the happens before is not present, the JVM is allowed to assume that only the current thread is accessing / updating the variable. What the JIT compiler actually does depends on all sorts of things, and it is not generally helpful to go into details.

It is also worth noting that volatile is not necessarily the best (most efficient) fix for a memory visibility flaw.

References:

• JLS 17.4 - Memory Model
• Is volatile expensive?

Answer 3

without any synchronization or volatile keyword, it's allowed to not read stopThread variable from memory, it can read it from cache (or even from register) where it put it first time.

What exactly it did and why it worked with sleep(1), we can only speculate. My guess is that first thread wrote stopThread = true before second thread read it. Maybe try starting looping thread first.