Cliff Click: Where the metal meets the JVM

Where the metal meets the JVM - very-veeery long interview with Cliff Click.

"The common hardware around today which would be multi-core X86s, has a very conservative memory model. It's much more conservative than the Java memory model. So, although the Java memory model might allow a lot more interesting threads interleavings, a lot more interesting ways in which unsynchronized globals can have their data shared between threads, the X86 memory model is much more constrictive, and so you'll get a much fewer possible interleavings and some races, some data-races will therefore be hidden, some bugs will be hidden from you on an X86 platform."

"Now these days, Sparc is also fairly conservative, they have what they call TSO, Total Store Order, it's very similar; Power's starting to get looser, so dual-core Power architecture will definitely have more flexibility in re-ordering and then if you go to something more exotic like Itanium or Azul hardware where their memory model is a lot looser, it still matches the Java spec, but a lot more orderings of memory operations are possible and that in turn mean that you get higher performance out of your individual CPUs and more data-race bugs and more possible memory interleavings. So, certain classes of bugs simply can't happen on an X86 that will happen on other hardware platforms."
"volatile, you know, it's, it's sort of this word that, not a lot of people have a clear understanding of"
"That said, the typical volatile, volatile read and volatile write combined have roughly the same costs as an uncontended lock, a lock where no other threads are competing on that particular lock. So those costs are pretty comparable that sum of those two costs. How if you have contention, even very little amounts of contention, the cost for that lock will increase dramatically. And so one of the things you can say, if you can get away with it, if you can define your program such that you can use volatiles to get an operation done instead of a lock, then it's effectively the same as the cost of an unsynchronized lock, it *is* cheaper."
"For locks that are contended, you need a different algorithm. That's a hard one. And that's the reason that multi-thread, multi-core programming is going to be hard for long time to come. People have to go and hack their code."
"all languages, doesn't work well with multi-threading. We don't know what the right programming model is. Uh, you know, locks work correctly but they're hard to scale up. And other people proposing other things such as transactions or you know, "atomic" keyword, they have their own different problems. They're not the same problems as locks but they're no better and they're no worse, they're just different. And I don't really know of a solution that tells you how to write parallel programming, you know, how to write big complicated things parallel"
"So, so lock free and thread safe are hard to do. For the experts, they're hard to do. There are some things floating out there now that fall in that category, I have something on SourceForge, I think it's called high-scale-lib for short for high scale libraries and it's a, right now, it's a single library of a lock-free HashMap, I can demonstrate scaling all the way up, to a maxed out Azul box at 768 CPUs with all the CPUs reading and writing concurrently without you know blocking in any sort."
"When you introduce caching, you're introducing multiple copies of the same thing, you know, and how do you manage to keep them synchronized"