That's one meaning of memory model. Historically, however, "memory model" refers to the theoretical way that a language represents memory, independently of platform. For example, see this presentation (http://www.cs.cornell.edu/courses/cs2022/2011sp/lectures/lec...) of "The C Memory Model" (which happens to deal with memory layout very intimately, because C is very close-to-the-metal).

The use of "memory model" to describe primarily threading/concurrency behavior seems to be a Java innovation that's been picked up by the Go community.

There's a footnote for the first sentence of TFA that addresses this.

You mean this?

"² I’m calling these six conceptualizations “memory models”, even though that term used to mean a specific thing that is related to 8086 addressing modes in C but not really related to this. (I’d love to have a better term for this.)"

I think that's even more wrong. The Wikipedia article gives a pretty good idea what the term means.

I think a good term for what he's talking about is "data [structure] memory layout".

He's just using the term archaically. Before caches were combined with SMP on consumer level systems (which is remarkably recent), the term 'memory model' did mean various forms of data layout decisions.

The 8086 thing was legitimately called a memory model, choosing how the distinction between the 64k segments would be treated logically by your program. https://en.wikipedia.org/wiki/Intel_Memory_Model

> The 8086 thing was legitimately called a memory model...

Damn, completely forgot about that despite using many of those segmentation rules like "tiny", "large" and so on a long long time ago.

The wikipedia article talks about one thing the term means. The thing the article talks about is definitely not data structure layout in memory, though.

Some passages are suggesting otherwise:

"In this object-graph memory model, if you have several entities of the same type, each one will be identified by a pointer, and finding a particular attribute of an entity involves navigating the object graph starting from that pointer."

I consider even the Cobol case as a kind of data structure, although a very limited and inflexible one:

"For example, an account object might have an account-holder field from bytes 10 to 35, which might contain a middle-name field from bytes 18 to 26."

Sayeth Wikipedia https://en.wikipedia.org/wiki/Data_structure:

"In computer science, a data structure is a particular way of organizing and storing data in a computer so that it can be accessed and modified efficiently"

Anyways, I kinda agree with you as well. Usually when talking about data structures it's related to some particular algorithm, say a red-black tree.

The first thing you quoted says absolutely nothing about layout. But more importantly, layout might come up but it's not what the article is about and it does not use the term 'memory model' as a stand-in for layout.

I consider that first thing as data is laid out in more or less random [0] locations, with pointers between objects holding the whole thing together.

I guess we understand (memory) layout differently. How'd you define it?

[0]: Random as in allocated addresses may vary between invocations.

You don't know if it's laid out 'at random' because, again, the thing is not actually about layout.

I think you're getting a little hung up on this being 'wrong' and missing what the thing is trying to convey. Scroll down to the bits about SQL or hierarchal filesystems.

I think a critical approach you can try is that maybe these things are different in some important ways and perhaps that's why there is no obvious unified term that comes to mind to describe them and see where that takes you. 'Kragen confused some overarching abstraction he's trying to describe with "memory layout"' is likely neither true nor fruitful.