Turns out that the answers and the ensuing discussions only consolidated my original reasoning. I now have something in the way of a proof:

1. take the case where the reading thread executes in full before the writing thread starts executing;
2. note the synchronization order that this particular run created;
3. now shift the threads in wall-clock time so they execute in parallel, but maintain the same synchronization order.

Since the Java Memory Model makes no reference to wall-clock time, there will be no obstructions to this. You now have two threads executing in parallel with the reading thread observing no actions done by the writing thread. QED.

Example 1: One writing, one reading thread

To make this finding maximally poignant and real, consider the following program:

static volatile int sharedVar;

public static void main(String[] args) throws Exception {
  final long startTime = System.currentTimeMillis();
  final long[] aTimes = new long[5], bTimes = new long[5];
  final Thread
    a = new Thread() { public void run() {
      for (int i = 0; i < 5; i++) {
        sharedVar = 1;
        aTimes[i] = System.currentTimeMillis()-startTime;
        briefPause();
      }
    }},
    b = new Thread() { public void run() {
      for (int i = 0; i < 5; i++) {
        bTimes[i] = sharedVar == 0?
            System.currentTimeMillis()-startTime : -1;
        briefPause();
      }
    }};
  a.start(); b.start();
  a.join(); b.join();
  System.out.println("Thread A wrote 1 at: " + Arrays.toString(aTimes));
  System.out.println("Thread B read 0 at: " + Arrays.toString(bTimes));
}
static void briefPause() {
  try { Thread.sleep(3); }
  catch (InterruptedException e) {throw new RuntimeException(e);}
}

As far as JLS is concerned, this is a legal output:

Thread A wrote 1 at: [0, 2, 5, 7, 9]
Thread B read 0 at: [0, 2, 5, 7, 9]

Note that I don’t rely on any malfunctioning reports by currentTimeMillis. The times reported are real. The implementation did choose, however, to make all actions of the writing thread visible only after all the actions of the reading thread.

Example 2: Two threads both reading and writing

Now @StephenC argues, and many would agree with him, that happens-before, even though not explicitly mentioning it, still implies a time ordering. Therefore I present my second program that demonstrates the exact extent to which this may be so.

public static void main(String[] args) throws Exception {
  final long startTime = System.currentTimeMillis();
  final long[] aTimes = new long[5], bTimes = new long[5];
  final int[] aVals = new int[5], bVals = new int[5];
  final Thread
    a = new Thread() { public void run() {
      for (int i = 0; i < 5; i++) {
        aVals[i] = sharedVar++;
        aTimes[i] = System.currentTimeMillis()-startTime;
        briefPause();
      }
    }},
    b = new Thread() { public void run() {
      for (int i = 0; i < 5; i++) {
        bVals[i] = sharedVar++;
        bTimes[i] = System.currentTimeMillis()-startTime;
        briefPause();
      }
    }};
  a.start(); b.start();
  a.join(); b.join();
  System.out.format("Thread A read %s at %s\n",
      Arrays.toString(aVals), Arrays.toString(aTimes));
  System.out.format("Thread B read %s at %s\n",
      Arrays.toString(bVals), Arrays.toString(bTimes));
}

Just to help understanding the code, this would be a typical, real-world result:

Thread A read [0, 2, 3, 6, 8] at [1, 4, 8, 11, 14]
Thread B read [1, 2, 4, 5, 7] at [1, 4, 8, 11, 14]

On the other hand, you’d never expect to see anything like this, but it is still legit by the standards of the JMM:

Thread A read [0, 1, 2, 3, 4] at [1, 4, 8, 11, 14]
Thread B read [5, 6, 7, 8, 9] at [1, 4, 8, 11, 14]

The JVM would actually have to predict what Thread A will write at time 14 in order to know what to let the Thread B read at time 1. The plausibility and even feasibility of this is quite dubious.

From this we can define the following, realistic liberty that a JVM implementation can take:

The visibility of any uninterrupted sequence of release actions by a thread can be safely postponed until before the acquire action that interrupts it.

The terms release and acquire are defined in JLS §17.4.4.

A corrollary to this rule is that the actions of a thread which only writes and never reads anything can be postponed indefinitely without violating the happens-before relationship.

Clearing up the volatile concept

The volatile modifier is actually about two distinct concepts:

1. The hard guarantee that actions on it will respect the happens-before ordering;
2. The soft promise of a runtime’s best effort towards a timely publishing of writes.

Note the point 2. is not specified by the JLS in any way, it just kind of arises by general expectation. An implementation that breaks the promise is still compliant, obviously. With time, as we move to massively parallel architectures, that promise may indeed prove to be quite flexible. Therefore I expect that in the future the conflation of the guarantee with the promise will prove to be insufficient: depending on requirement, we’ll need one without the other, one with a different flavor of the other, or any number of other combinations.