To be more specific, when I said that C4 "emulates" the Vega architecture, I was referring the way that you presumably need to be able to invalidate an operation when another thread concurrently reads or writes to shared memory in the middle of a transaction (i.e. copying a black and updating pointers). By emulate, I meant you need to construct a primitive that provides an efficient lock-free large block copying operation, similar to what the Vega cache system provides. Of course, that's only a primitive--you need to then build compound operations atop that, and there's more than enough engineering there to keep people busy for quite awhile.

Again, if you can claim that in fact your page mapping and protection schemes are not analogous to the transactional memory support in the Vega hardware (which looks to be both small block transactional memory tied into the cache controller, as well as some useful page-level operations built into the memory controller), then mea culpa.

Sheesh. Read the C4 paper. See if you can point to a single place in the paper where we mention transactional memory. Or a need to invalidate an operation in the middle of some transaction. Or any form of emulation. C4 simply doesn't do or make any use of that stuff.

You seem to conflate Vega's [very cool] hardware transactional memory capabilities (SMA, OTC) with GC. Vega never used transactional memory for GC purposes. It used transactional memory to support OTC and transparent concurrent execution of synchronized blocks. Nothing to do with GC, and nothing to do with C4.

And yes. I can assertively "claim" that the page mapping and protection schemes in C4 are not analogous to the transactional memory support in Vega, and have nothing to do with caches or memory controllers. Vega (just like C4 on x86) used page mapping and protection schemes for GC purposes.

So as the designer you're telling me that your lock-free (excluding the locking necessary for updating the page tables) and possibly wait-free algorithm (unsure on the last part), simply can't be modeled as a transactional memory algorithm? If you're willing to claim that, I'll acquiesce. Because excluding the low-level details and the context of what's happening, the barrier algorithms look exactly like what you'd get trying to implement, e.g., the N-word transactional memory copying algorithms from 30+ years ago--in particular what Hoare laid out in the paper proving the universality of the LL/SC primitive--in a way that works on x86 for the JVM.

Regarding performance: number of allocations is not the same as transactional throughput. If you can also claim that the object system and VM subsystem of your JVM has no overhead over a traditional lock-based system (which doesn't use extensive mapping tricks, nor needs as many atomic operations), _or_ if you can show me TPC benchmarks where C4 is faster than the other existing locking collectors, I'll acquiesce.

Otherwise, I'm quite comfortable sticking to my guns.

I think what you've written is exceptional in numerous regards. And I don't mean to diminish the work in the slightest, but to only counter the hype--namely, that the algorithm uses techniques unknowable to others, or (as sometimes discussed elsewhere) that it's solved the problem of implementing a generic transactional memory model using regular x86 primitives.

Let's see:

1. We never claimed the algorithm uses "techniques unknowable by others" (um, we published the algorithm, so it's obviously knowable by others)

2. We never claimed to have implemented generic transactional memory using regular x86 primitives.

So you can consider this made up hype countered.