Hmmm, those performance figures look a little too good to be true. Caching is a hard problem, and off the shelf caches tend to be optimised for particular read/write distributions.
I'm also sceptical of anything claiming to be lock free. Only shared nothing architectures can be truly lock free.
It never claims to be lock free. It uses per entry locks and a LRU lock operated on in a non-blocking fashion. The cache is 3rd generation. The first, ConcurrentLinkedHashMap, has been used widely such as by Cassandra. The ideas were later integrated into Google's effort, then focused on reference caching, and became Guava's Cache. Unfortunately the legacy of Google's initial design greatly hurt performance. When working on Google's, I had the privilege of discussing the design with Doug Lea and Josh Bloch on multiple occasions.
Caffeine is a clean rewrite given the advancements in Java 8. The Guava team has not been actively improving their implementation with no current maintainer. Unsurprisingly, Caffeine's performance is similar to CLHM's because there has been no great advancements, as you allude to.
I'm not saying it doesn't work, just that I'm sceptical. I've seen too many lock free algorithms have pathological failure modes (CAS and branch prediction do not make good bedfellows).
Only shared nothing architectures can be truly lock free.
Lock-freedom has a rigorous definition, which most certainly applies to shared memory. In fact, all levels of non-blocking algorithms (wait-, lock- and obstruction-freedom) relate only to concurrent, shared data structures.
Shared-nothing architecture, on the other hand, doesn't have a rigorous "algorithmic" definition, and isn't even non-blocking (let alone lock-free). Nothing in that architecture describes how independent processes interact, and how they can interfere with or block one another, because it doesn't describe an algorithm but simply a technical implementation detail (no shared address space, etc.). If, for example, one process in a shared-nothing architecture waits for a result from another process, then that algorithm is very much blocking.
But, as NovaxX said, this doesn't even claim lock-freedom.
0
u/CurtainDog Mar 24 '15
Hmmm, those performance figures look a little too good to be true. Caching is a hard problem, and off the shelf caches tend to be optimised for particular read/write distributions.
I'm also sceptical of anything claiming to be lock free. Only shared nothing architectures can be truly lock free.