|
|
|
|
|
by mjpt777
4245 days ago
|
|
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. |
|
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.