Dealing With JVM Limitations in Apache Cassandra

http://nosql.mypopescu.com/post/17940621304/dealing-with-jvm-limitations-in-apache-cassandra

by pron • 14 years ago

21 8 14 years ago

nosql.mypopescu.com

shin_lao3• 14 years ago

Cliff Click: Many concurrent algorithms are very easy to write with a GC and totally hard (to down right impossible) using explicit free.

Wrong, we did it.

sparky2• 14 years ago

Did what, exactly? The 'impossible' bit may be meant in more of a practical sense than theoretical, since obviously you can just implement your own garbage collector if it comes to that, but it's well-established in the lock-free algorithm literature that algorithms that assume garbage collection are less complicated than those that use some other SMR (scalable memory reclamation) scheme like hazard pointers, epochs, or Pass The Buck. My own experience porting ConcurrentSkipListMap from JDK6 to C supports this.

Reference counting is usually not too bad from a complexity standpoint, but doesn't perform well for contended structures and has the cycle-collection problem, which may or may not matter depending on the algorithm.

I guess my point is: if you've solved this problem, the rest of us would love to hear how you did it :)

shin_lao3• 14 years ago

Our software is written in C++11 and we are highly asynchronous AND lockfree.

This was neither hard, nor impossible and surprisingly (<-- irony) we have excellent performance with a very low memory footprint (in other words, all the problems discussed in the post don't exist for us).

We have a custom memory allocator for scalability. As for memory management we either don't copy it (zero-copy) or when we have to track the lifetime, we use reference counted memory (which does not have the problems you point out when correctly implemented and used).

We don't have (yet) a mapreduce-like feature, but this is coming.

Actually the most difficult part was the network layer.

We have a workable version with which you can play here: http://www.wrpme.com/ Feel free to contact me in private if you have more questions.

the_paul• 14 years ago

"Many concurrent algorithms are very easy to write with a GC and totally hard (to down right impossible) using explicit free."

This is not the same as:

"All concurrent algorithms are very easy to write with a GC and totally impossible using explicit free."

So if you've written a concurrent algorithm with an explicit free, congratulations, but that doesn't mean the statement is wrong.

eternalban• 14 years ago

Cliff Click communicates telegraphically: He mentions GC, so you can immediately update the statement with "operating on a larger than memory data sets" as that is when you need GC. Obviously basic concurrency primitives will allow trivial concurrent code if a fixed set of memmory pages are simply allocated and then assigned a fix isolation level e.g. via a allocation of a large array that fits in L3 and is forever resident.

However if the data set is constantly changing, because either you are churning through a lot of short lived memory objects or you have structures e.g. trees spanning a very large number of pages, then you have a memory management problem to address. Either way you are constantly blowing your L2 (and possibly L3) caches. Naturally, limiting those page swaps is the key to high performance. Concurrency exacerbates this demand (which is present even for single threaded servers) by placing isolation requirements on pages and data. So the name of the game is memory page management, e.g. "GC" in Dr. Click speak. His choice of telegraphic word is also highly informed: he is nailing the fact that removal of garbage is basically what the allocators all must struggle with and that the GC makes or breaks the allocator (for such high performance systems).

So I would flip Click's pithy statement and state verbosely:

High performance concurrent computing's requirement for data locality and isolation inevitably require very sophisticated memory allocation and memory pool management sub-systems. And beyond simple but effective heuristics such as object creation time (for locality) any further significant gains to be had can only be delivered by the garbage collection mechanisms of the memory manager.

Dealing With JVM Limitations in Apache Cassandra

Related Stories