The X86 memory model is "conservative" in the sense that it puts strong restrictions on the order of observed loads and stores between cores. Azul and IA64 did not. Hence "sloppy" code - but technically correct (at least it would compile) might run on an X86 and break on the IA64. Cliff

The usual term is strong versus weak memory models. In x86 and SPARC (TSO), the only reordering in hardware that you can do is having reads complete before pending writes--all writes happen in order, all reads happen in order, and a pending read must complete before a pending write can. Other architectures allow much more reordering at the hardware level.

If you know the C++11 memory model, x86 and SPARC (TSO) basically make all memory loads implicitly atomic release/acquire. In contrast, most machines follow something akin to release/consume (the DEC Alpha famously has a basically broken memory model that allows *p to complete before p).

Ah OK, strong vs weak I am familiar with, I think that's probably a more idiomatic way to phrase that then. Interesting bit of history on the DEC Alpha. Thanks.

Azul has their own hardware for facilitating pauseless garbage collection with their JVM.

I recall they have a pure software pauseless JVM now as well, but it's not nearly as high performing.

Azul hardware had a very large core count of low-performing cores. If you had enough parallelism then it was hard to beat - but most applications didn't have enough parallel work, so the market wasn't big enough

I… just got corrected by Cliff Click~! (You're like my language implementation hero (along with Mike Pall).)

Vega sounds like it would have a nice niche in network processing. Shame it didn't find a big enough market. It was pretty interesting from what I read.

Thanks, I had no idea they started with hardware. For anyone else not that familiar it looks like Vega is the hardware appliance and Zing is the VM version.

I have board with 2 Vega chips in my living room - 24 cores each; each a full 64-bit RISC with 32 registers and ie754 FP math, read & write barriers in hardware; inline-cache virtual calls in hardware, and transactional memory. Later chip versions had 48 and then 54 cores, and you could jam 16 chips in a cache-coherent shared memory box - with top-10 supercomputer bandwidth. But you needed 54*16 parallel working threads to use it all. :-) Cliff

So in the bit of reading I've done it seems like the idea of read and write barriers in hardware were what allowed them to have puase-less GC and that was the primary reason for Azul producing hardware appliances. Is that accurate? At least initially?

What did that board cost you if you don't mind my asking? What does it cost you to run it is maybe a better question.

It was cheaper to run (power, heat, space) than the equivalent pile of X86's of that era and for years to come. Each box cost between $250k and $750k depending on cores & memory. You didn't buy one unless you had a specific scaling problem that scale-out x86's weren't cutting it.