in what architectures/OS other thread can see default nonfinal field values after constructor call?

Question

I'm trying to reproduce a memory visibility issue in case of insufficient object initialization for non-final fields (JLS 17.5 Final Field Semantics, FinalFieldExample class example). Where it stated "However, f.y is not final; the reader() method is therefore not guaranteed to see the value 4 for it"

I've tried this code:

public class ReorderingTest2 {


    public static void main(String[] args) {
        for (int i = 0; i < 2500; i++) {
            new Thread(new Reader(i)).start();
            new Thread(new Writer(i)).start();
        }
    }

    static class Reader implements Runnable {
        private String name;

        Reader(int i) {
            this.name = "reader" + i;
        }

        @Override
        public void run() {
            //System.out.println(name + " started");
            while (true) {
                FinalFieldExample.reader(name);
            }
        }
    }

    static class Writer implements Runnable {
        private String name;

        Writer(int i) {
            this.name = "writer" + i;
        }

        @Override
        public void run() {
            //System.out.println(name + " started");
            while (true) {
                FinalFieldExample.writer();
            }
        }
    }

    static class FinalFieldExample {
        int x;
        int y;
        static FinalFieldExample f;

        public FinalFieldExample() {
            x = 3;
            y = 4;
        }

        static void writer() {
            f = new FinalFieldExample();
        }

        static void reader(String name) {
            if (f != null) {
                int i = f.x;
                int j = f.y;
                if (i != 3 || j != 4) {
                    System.out.printf("reader %s sees it!%n", name);
                }
            }
        }
    }

}

As in previous my similar topic - I've tried on different PCs (from 2 to 8 cores) with Windows and even on our server-side Solaris 32 core box - I couldn't reproduce it: f.x and f.y - are always already proper-initialized.

For Intel/x86/x64 architecture as I got the answer - they have pretty much default memery guarantees which prevent such constructor logic reordering. Seems the same is true for Solaris/sparc too?

So in what architecture/OSes this reordering can be reproduced?

Answer 1

Alpha. Paul E. McKenney's book Is Parallel Programming Hard, And, If So, What Can You Do About It? has a chapter explaining thememory model of the most important platforms.

Answer 2

To get the result you want, you might try to turn on heavy optimization, so run the program in -server mode.

I first thought of making f volatile, but that would obviously screw the whole experiment.

Turn on the XML logging for the just-in-time compiler (if you are using the HotSpot JVM), and look at the generated machine code (using some external debugger or memory dumper). Then you can examine the generated code if that would even allow you to observe the result you want.

Answer 3

I suggest you acquire a copy of "Java Concurrency in Practice" and read Chapter 3 which details the JVM guarantees around locking and visibility. Your question has nothing to do with a specific architecture and everything to do with understanding happens-before in Java.

I think that you cannot repro the problem because there is a happens-before edge at the end of the FinalFieldExample constructor which is guaranteeing that x = 3 and y = 4;

BTW. The FinalFieldExample object is a bit of a mess. It wants to be a proper singleton, but you didn't code it that way. The lack of synchronization around the static "f" makes it more difficult than it should be to reason about the runtime behavior of this class. Methinks it should be a proper singleton with synchronization protecting access to the static "f" and you should be calling the writer and reader methods like...

FinalFieldExample.getInstance().writer();

Just sayin'

Answer 4

This should perhaps be a separate question... but it's very on-point. It's a more expansive version of a comment I made earlier.

The first part of section 17.4 of the jls says:

To determine if the actions of thread t in an execution are legal, we simply evaluate the implementation of thread t as it would be performed in a single threaded context, as defined in the rest of this specification.

The place I get hung up is understanding what "as defined in the rest of this specification" means, with regard to program order.

In the case at hand, the assignment

f = new FinalFieldExample();

is subject to assignment semantics (section 15.26.1), of which the following pertains. It is confusingly misformatted in the spec (the third step especially), I believe I have reformatted it to accurately reflect intent.

[Otherwise,] three steps are required:

1. First, the left-hand operand is evaluated to produce a variable. If this evaluation completes abruptly, then the assignment expression completes abruptly for the same reason; the right-hand operand is not evaluated and no assignment occurs.
2. Otherwise, the right-hand operand is evaluated. If this evaluation completes abruptly, then the assignment expression completes abruptly for the same reason and no assignment occurs.
3. Otherwise, the value of the right-hand operand is converted to the type of the left-hand variable, is subjected to value set conversion (§5.1.13) to the appropriate standard value set (not an extended-exponent value set), and the result of the conversion is stored into the variable.

This reads like a specification of single-thread "program order" to me. What am I misinterpreting?

An answer, perhaps, is that what is really intended is a "duck test" - if a single thread executes as if everything were done in the order specified, it's a correct implementation. But this section is written very differently from other places where this is made clear by using the word appear, e.g.:

The Java programming language also guarantees that every operand of an operator (except the conditional operators &&, ||, and ? :) appears to be fully evaluated before any part of the operation itself is performed.