Can compiler optimizations avoid writing to memory by operating exclusively in registers?

Context:

In multithreaded programming, one of the key challenges is ensuring that changes made by one thread are visible to others. While this issue is commonly tied to memory visibility, another potential factor is how compilers handle register caching for variables that are not explicitly marked as shared (e.g., without volatile or synchronization mechanisms).

Consider the following Java example:

public class Example {
    static boolean run = true;

    public static void main(String[] args) {
        new Thread(() -> {
            run = false;  // Producer updates the value
        }).start();

        while (run) {
            // Consumer waits for the update
        }
        System.out.println("Exited loop.");
    }
}

Here, the variable run is used to coordinate between two threads. Since it is not marked volatile or synchronized, a compiler might assume that the variable is thread-local. This raises an interesting question:

Could the compiler optimize access to run by caching it in a CPU register, avoiding writes to memory? If so, this would:

1. Prevent the cache-coherency mechanisms from triggering, as registers are core-local.
2. Result in the consumer thread never seeing the updated value, causing an infinite loop.

This scenario might adhere to program logic, but it could break the memory visibility guarantees expected in multithreaded environments.

---

The Question:

Is it possible, in practice, for modern compilers to optimize variable access such that the value is held exclusively in registers, bypassing memory writes entirely?

• If so, what are the circumstances that allow such behavior?
• How do modern memory models (e.g., JVM, x86) and compiler standards mitigate or prevent this scenario?

---

Goal:

The objective is to understand:

• Whether such optimizations are feasible in real-world systems.
• The mechanisms (if any) in compilers and architectures that ensure memory visibility in such cases.

In multithreaded programming, one of the key challenges is ensuring that changes made by one thread are visible to others. While this issue is commonly tied to memory visibility, another potential factor is how compilers handle register caching for variables that are not explicitly marked as shared (e.g., without volatile or synchronization mechanisms).

I think you are misunderstanding what it means to be a memory model. The memory model is concerned with reading from and writing to memory, and what memory is is defined from the context of the system that memory model works on. From the JVM perspective, any field read/write is a memory access. The compiler, therefore, must adhere to the memory model, and produces a valid mapping between the reads/writes in the source machine (the JVM abstract machine) to the reads/writes in the destination machine (the x86 machine for example). This means run = false and while (run) are memory accesses and they must adhere to the rules of the JVM memory model. The compiler can then from this memory model chooses not to materialize all of them, but this is a consequence of adhering to the memory model, not a factor you have to think about when reasoning about the memory model.

Here, the variable run is used to coordinate between two threads. Since it is not marked volatile or synchronized, a compiler might assume that the variable is thread-local.

This is incorrect, the compiler cannot assume that the variable is thread-local, as its accesses can be coordinated upon using other synchronisation devices. For example, the termination of a thread happens before the return of any join method on that thread object. And it is perfectly race-free for the consumer to join with the producer before reading run, and it would be incorrect for the compiler to elide the write in that case. As a result, I can be almost certain saying that the compiler cannot elide the write to run.