
Akka and the Java Memory Model - DanielRibeiro
http://blog.typesafe.com/akka-and-the-java-memory-model
======
prodigal_erik
Something went wrong in machine architecture. If the intent is to produce and
ship a fully initialized object graph from core P to core C for immediate
consumption, well, why can't core P just write dirty lines straight into core
C's cache? Right now core P generally has to completely flush its write buffer
and broadcast invalidations to all other cores, even the ones with no
references to that memory and no reason to care about its contents. Memory
barriers are seeming more like manual allocation to me, one of those things
that humans just shouldn't need to be involved with, because it's nothing more
than an opportunity to make subtle mistakes which are agonizing to
troubleshoot.

~~~
pmjordan
_Right now core P generally has to completely flush its write buffer and
broadcast invalidations to all other cores, even the ones with no references
to that memory and no reason to care about its contents._

That's not strictly true. Modern CPUs have snoop filters and other mechanisms
to reduce cache communication. If they didn't, the buses would be horrendously
congested (you can indeed render the snoop filter ineffective by writing bad
code).

In any case, it's not clear to me what alternative you're suggesting. x86 is
about the easiest architecture for the programmer to reason about in terms of
cache coherency, and CPU designers seem to run into scalability problems at
every doubling of x86 core count. I fail to see how making even more coherency
guarantees at the hardware level will improve matters. Yes, you can make it
very easy to reason about (even in software, at the VM level), but you'll end
up with terrible performance.

