Home » forums » LtU Forum

does your language need a memory model?

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?

By el-vadimo at 2010-08-06 20:12 | LtU Forum | previous forum topic | next forum topic | other blogs | 6912 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Was this meant for the

Was this meant for the homepage?

By Ehud Lamm at Fri, 2010-08-06 21:30 | login or register to post comments

It depends

If you have a purely functional language, you do not need a memory model. Otherwise, if mutable shared memory is involved, you do need a memory model of course. Piggybacking on the Java MM means that people need to understand the details of your compiler in order to understand your language. So basically, your compiler becomes your programming language semantics. If that's ok for you, then of course piggybacking is an option. But probably you should piggyback only during an experimental phase and then see if you can come up with reasonable rules in terms of your language that govern the observed behavior.

By Steven Obua at Fri, 2010-08-06 21:42 | login or register to post comments

parallel vs. concurrent

Re: comment-61225…

Q: 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?

A: If you have a purely functional language, you do not need a memory model.

Either this means the JVM cannot furnish a target backend for a pure functional language (not to be confused with the Pure functional language), or it means that yes, it is reasonable to not have a memory model for some languages that target the JVM. I can't tell which interpretation is correct.

More to the point, having skimmed the literature, I'm not sure what to make of the claim that “purely functional languages” (is that the same as “pure functional languages”?) are not burdened by the need for a memory model. If we assume for a moment that Haskell is one such language, don't things like MVar and IORef require some sort of MM?

More generally, I'm prepared to be convinced that parallel functional languages do not need a memory model. I'm dubious as to whether the claim holds for concurrent languages.

In other news, Z-Bo is slogging through a backlog of past CACM issues. He made it as far as August 2010.

By el-vadimo at Thu, 2011-03-17 01:53 | login or register to post comments

Concurrency and MM

There are many concurrent paradigms that don't require a memory model. A few of my favorites would be:

  • temporal logic programming (e.g. Dedalus and Bloom)
  • concurrent constraint programming
  • futures passing or distributed unification (e.g. Oz/Mozart)
  • functional reactive programming

These simply lack a 'memory' abstraction, so don't need a memory model. ;-)

don't things like MVar and IORef require some sort of MM?

Well, sure, but the question implies confusion regarding the semantic nature of memory models. Consider: If I modeled Java in Haskell, would I also be modeling Java's memory model? If I implemented an interpreter for Java in Haskell, would I be implementing Java's memory model? If I model an imperative language as a monad in Haskell, will it have a memory model? Yes, yes, and yes.

Nobody would claim that Haskell's "IO" is a purely functional language! Rather, it's a semi-decent imperative language - and you can functionally construct programs of this language then execute them in Haskell's toplevel.

By dmbarbour at Thu, 2011-03-17 03:19 | login or register to post comments

Great White Buffalo

The reason Vadim was asking if MVar required some sort of MM is because people do crazy things with Haskell compiler plug-ins and nobody knows semantically if they're safe or not. When you jack up your compiler (and language) with non-standards features, and things crash, you run the risk of corrupting stuff in parts of your program you otherwise thought were "guaranteed" to be safe.

I can't think of a particular example right now, but I know I've seen it with HDBC.

By Z-Bo at Tue, 2011-03-22 03:30 | login or register to post comments

* In the forward or the reverse direction?

...

By johnwcowan at Sun, 2011-03-20 20:23 | login or register to post comments

I'm just random

This morning I was cleaning out my closet and noticed a bunch of unread CACM magazines. But the August 2010 issue I missed because I forgot to renew the subscription! And I was on vacation when Vadim initially posted this thread, so I missed it.

Vadim: Good catch! Wish I read your post sooner!

By Z-Bo at Tue, 2011-03-22 03:31 | login or register to post comments

Intanium

Intel and HP (formerly Tandem) developed the Itanium processor (see: http://en.wikipedia.org/wiki/Itanium) for parallel processing with intentions for it to replace the i86 series for large servers.

Yet, Intel continues to upgrade the i86 architecture for greater parallelism. They have done an outstanding job of managing quality and complexity while upgrading an 8-bit microprocessor into a 64-bit superscalar multiprocessor. I suspect they will do it again and provide the necessary memory model.

By Ed Earl Ross at Fri, 2010-08-06 21:53 | login or register to post comments