C2/HotSpot uses a MemBarrier / MemFence node type for these. Serializes the memory ops as needed. Used to implement the Java memory model on all hardware. Sometimes (x86) the ops encode as (empty), sometimes its a Real Fence op.
Thanks for the info. So in practice there are node types that encode sequential flow as needed. I wonder if the other way around works: keep the CFG form for side effects and only promote SSA values to be "floating".
Simple (https://github.com/SeaOfNodes) is a compiler tutorial featuring the Sea-of-Nodes IR, with ports in Java (@cliffclick), Go (@yardenlaif), Rust (@RobertObkircher), and C++ (@Hels15), with help from @XmiliaH, @ThaliaArchi. If you'd like to help reach out to cliffc@acm.org or on GitHub.
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.
Fun stuff I've been doing with the H2O project is basically using nearly-pure Java (some Unsafe) to hold onto numbers with better efficiency than e.g. int[], and giving out an easy-enough-to-use API for writing parallel & distributed code over an Array-like API. i.e., feels "almost like an array", and "for-loops" run at memory bandwidth speeds and also parallel and distributed.
Cliff
Nearly all the work you allude to is done in other threads - which indeed consume machine resources (CPU cycles, memory bandwidth). If your application does not burn all cores/bandwidth then the GC work is all done on the idle/spare machine resources. At the limit though, indeed you'll have to slow down the Application so that GC can play catchup - and bulk/batch stop-the-world style GC's require less overhead than the background incremental GCs
Cliff
Sorta kinda all of the above.
C4 the algo has no pauses, but individual threads stop to crawl their own stacks. i.e., threads stop doing mutator work, but only 1-by-1, and only for a very short partial self-stack crawl.
C4 the impl I believe now has no pauses also.
HotSpot the JVM has pauses, and yes much Zing was on forcing these pause times down.
Cliff
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.
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
It means what it says it means?
"fragile" code is code that can't be touched because touching it causes it to "break" - exhibit bugs that can't easily be fixed.
"fluffy" code is bulky code: code that says in 1000 lines what could better be said in 10 lines.
Cliff
