I'm sorry but this analysis is completely wrong. I don't work for Azul but have used C4 and spent time studying it. C4 does not use transactional memory, it does however employ a very elegant lock-free algorithm which allows continuous concurrent compacting collections. BTW that is why it is called C4.
I can tell you from first hand experience that is does not have throughput issues. The truth is quite the opposite as it is the only JVM I've found scales well on large core count or large memory systems.
Do you have experimental evidence to back up your claims or are they just conjecture?
Having studied C4 it is important to note that to get the best out of it you need to allow it to avail of a large heap. If your mindset is to keep the heap small, as you would with many other collectors, then you will be restricting the C4 collecting algorithm from performing at its best. Don't be shy, give it a big heap to play with. The obvious consequence to this is that C4 is not ideal for constrained memory systems - but that is not the world the majority of our servers live in today.
Amendment: All the above applies to Zing (C4) on Intel x86_64.
There's no other way to implementation a lock-less compacting (i.e. copying) collector than by using transactional memory algorithms. Period.
I've never used C4, and I don't even program in Java. But I have personally studied and implemented transactional memory algorithms, and C4 fits perfectly into that mold. In fact, what originally made me interested in transactional memory was figuring out how C4 worked.
And I did figure it out. I figured it out even before they published their 2011 paper, which I just discovered. And unsurprisingly everything in there is precisely as I predicted. It couldn't have been otherwise once you understand the fundamentals.
Um. There are 30 years worth of academic publications covering concurrent compacting collectors that don't need or use transactional memory, and are implementable on commodity hardware with no emulation or specialized instructions. C4 is just one of many examples of this fact. Sure, C4 does some cool new things, but trying to move or copy memory transactionally isn't one of them.
Whatever it is you think you figured out about how C4 works seems to be wrong. You may want to re-examine those fundamentals.
I asked the question if this is based on conjecture or experimental evidence. I'm happy to base my view on experimental evidence from my own research and testing.
I can tell you from first hand experience that is does not have throughput issues. The truth is quite the opposite as it is the only JVM I've found scales well on large core count or large memory systems.
Do you have experimental evidence to back up your claims or are they just conjecture?
Having studied C4 it is important to note that to get the best out of it you need to allow it to avail of a large heap. If your mindset is to keep the heap small, as you would with many other collectors, then you will be restricting the C4 collecting algorithm from performing at its best. Don't be shy, give it a big heap to play with. The obvious consequence to this is that C4 is not ideal for constrained memory systems - but that is not the world the majority of our servers live in today.
Amendment: All the above applies to Zing (C4) on Intel x86_64.