kilim

http://rdc.taobao.com/team/jm/archives/533

http://www.ibm.com/developerworks/cn/java/j-javadev2-7.html

What is Kilim?

Kilim is a message-passing framework for Java that provides ultra-lightweight threads and facilities for fast, safe, zero-copy messaging between these threads.

It consists of a bytecode postprocessor (a "weaver"), a run time library with buffered mailboxes (multi-producer, single consumer queues) and a user-level scheduler and a type system that puts certain constraints on pointer aliasing within messages to ensure interference-freedom between threads.

---

Why?

Hardware facilities are getting distributed, from the micro to the macro levels -- increasing numbers of cores, CPUs in a box, boxes in a data center to a multitude of data centers. The current crop of software architectures, languages and idioms are not suited to this trend. Here are a few reasons:

• A multi-core/CPU box is internally a distributed system, but operating systems and hardware manufacturers go to great lengths to provide an illusion of local shared memory. In reality, the illusion is never complete, which is why programmers have no option but to learn about non-trivial memory models and consistency schemes.
• The problems with shared memory has been well documented [ PDF ].
• Different mindset between "concurrent programming" and "distributed programming". Programmers have to deal with both (even embedded systems have network interactions) and require separate sets of tools for verification, profiling and debugging these two patterns.
• The "events vs. threads" debate unnecessarily conflates two problems: threads are considered bad because they are (a) heavyweight (which doesn't have to be the case) and (b) the thread paradigm is implicitly associated with shared memory locking constructs that are error-prone, which again does not have to be the case. As Kilim demonstrates, it is possible to have lightweight threads that are just as lightweight as state machines, yet provide the automatic stack management feature (there's no need for the "return to the mainloop" mentality).

The combination of lightweight threads plus message-passing is a good fit for the emerging world. It permits us to blur the line between concurrency and distribution -- the API (send/receive) is the same (although the failure modes and frequencies may be different), and allows a uniform set of tools for debugging, profiling, and verification. For example, the most common verification tool in practice, the SPIN model checker, is based on a message passing mindset. There is a good reason why Tony Hoare used "communicating sequential processes" as a model for verification.