Lambda the Ultimate

Does every shiny new language need a memory model (MM) these days? And if it does, should the language specifiers/implementers work closely with the likes of Intel and AMD to ensure that the MM model defined by the language is in harmony with the MM informally defined by the CPU vendors?

What's a memory model, you ask? Per Sarita V. Adve and Hans-J. Boehm:

The memory model, or memory consistency model, is at the heart of the concurrency semantics of a shared-memory program or system. It defines the set of values that a read in a program is allowed to return…

In other words, it allows you to reason about statements like this one:

…each sub-component of the data structure is allocated and written to by only a single thread and never written once published, so while there is workflow synchronization of course, there is none for the data itself. When you share an ‘immutable’ data structure with another thread, the memory will need to be made visible to the processor running that thread, but it being ‘read-only’ means that can be done so in the least cost way, and subsequent reads can be free of all but the most minimal memory coherence protocols.

(Sounds like this description assumes sequential consistency whereby neither the underlying JIT compiler nor the CPU is allowed to reorder instructions or use CPU-level store buffers.)

Things like that are discussed in Adve and Boehm's new paper Memory Models: A Case for Rethinking Parallel Languages and Hardware (CACM vol. 53, no. 8, pp.90-101) that is currently available for free for a limited time, before it is moved behind the ACM paywall. (It's a safe bet though that this paper will get to be as widely mirrored as Boehm's earlier paper Threads Cannot be Implemented as a Library.)

Here's a tangential question. If your shiny new language is designed to compile to Java bytecode and run on the JVM, does it still need a memory model of its own, or can it piggyback on the Java MM?