InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Kilim - actors and message passing in Java

Posted by Niclas Nilsson on Jun 26, 2008

Sections
Development,
Architecture & Design
Topics
Java ,
Architecture ,
Performance & Scalability
Tags
Concurrency

As discussed in The multicore crises: Scala vs. Erlang, massage passing and the actor model of concurrency is one promising way for the massive parallelization needed to utilize current and especially future CPUs. Erlang has it built in from the start and Scala incorporated the Scala Actor library into it’s framework. But there is also a pure Java solution - Kilim

Kilim is a message-passing framework for Java that claims 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.

And it seems to perform well. According to Sriram Srinivasan in his Google Tech Talk, task-switching in Kilim is 1000x faster than Java threads and its message-passing is 3x faster than Erlang.

Kilim works with code annotations on methods and arguments. A method is annotated as @pausable if it directly it indirectly calls other pausable methods, which somewhere in the call chain will result in calls to Kilim methods, such as Actor.sleep() or Mailbox.get(). The annotated code is transformed by the bytecode weaver to code in a continuation passing style. Continuations are native in some languages but has been retrofitted into Java code before in well known web frameworks and web servers, such as RIFE and Jetty.

Arguments on the other hand are annotated as @free, @cuttable or @safe. These argument qualifiers are described in an ECOOP 2008 presentation by Sriram Srinivasan and Alan Mycroft:

These qualifiers can be understood in terms of two orthogonal capabilities of an object in a tree: first, whether it is pointed to by another object or not (called a root in the latter case) and second, whether or not it is structurally modifiable (whether its pointer-valued fields are assignable). The latter is a transitive property; an object is structurally modifiable if its parent is.

Given this, an object is free if it is the root of a tree and is structurally modifiable. A cuttable object may or may not be the root, but is structurally modifiable. An object with a safe capability cannot be structurally modified (transitively so), and does not care whether or not it is the root.

The actor model is popping up in more and more contexts, and no matter which language or platform you will program in in the future, the concept is likely to be in important one.

Cool! by Neil Ellis Posted
Can he switch his project page back to black text on white background ? by Dorel Vaida Posted
Re: Can he switch his project page back to black text on white background ? by Neil Ellis Posted
Project Name? by Jeremy Gerrits Posted
A few clarifications. by sriram srinivasan Posted
Java and Actor Model - eh! by Bjorn Borg Posted
Kilim - what's the matter here? by Bjorn Borg Posted
  1. Back to top

    Cool!

    by Neil Ellis

    Thanks Niclas


    Nice to see a Java only implementation I will definitely be checking this as a possible execution model type in Einstein. What's interesting is the way that he has chosen to annotate the degree of mutability. I think that thinking in gray-scale rather than monochrome is the way forward for general purpose (rather than specialist) scalability techniques. I'm not convinced yet by the absolutism of some languages/frameworks with rigid restrictions, like those in functional programming; I think we have a lot to learn from the results of using these idioms but need to be able to say the degree of, for example, idempotency, mutability, concurrency etc. that we desire or can assure etc. And exploration in this area is very interesting to see.

    Definitely on my one to watch list!


    All the best

    Neil

  2. Back to top

    Can he switch his project page back to black text on white background ?

    by Dorel Vaida

    Cause I'm used to associate that with work you know ? White text on black background is for MUD-ing mind you ?

  3. Back to top

    Re: Can he switch his project page back to black text on white background ?

    by Neil Ellis

    Man Black is the new White!




    You may have noticed from my project page (the above link to Einstein) I am a little biased in this area :).


    All the best

    Neil

  4. Back to top

    Project Name?

    by Jeremy Gerrits

    Is this project related to the other Java project that's been around since 2002 that has the same exact name?

    kilim.objectweb.org/

  5. Back to top

    A few clarifications.

    by sriram srinivasan

    On the term Actor



    One of the big features of Actors, as used by the originators of the term (Carl Hewitt, Gul Agha), is isolation from one another. There is no point doing concurrent programming if you cannot isolate easily.




    In Scala's actor model, isolation is not enforced; it is obtained by convention; the programmer must use immutable messages or be "very careful" while exchanging mutable messages.




    On Continuations



    A continuation is a snapshot of both the data and control planes. In that sense, Jetty doesn't provide continuations (it only restores the control plane, but no support on the data plane; it leaves it to the programmer to figure out which variables to restore, and where to store them before yielding.



    Kilim can be downloaded at kilim.malhar.net. There's an "IFAQ" (Infrequently asked questions) in the download that provides more comparisons.

    --sriram

  6. Back to top

    Java and Actor Model - eh!

    by Bjorn Borg

    For some reason actor model does not seem like a natural extension to Java. I am no James Gosling to say whether Java is meant to do this or not. Perhaps should we shift the blame on to the frameworks which have made actor model like an after-thought on Java? These weaving strategy implementations like Kilim, ActorFoundry, Actors Guild etc… have to take some blame for making actor models look very unnatural to Java development – putting a kink in every development step and development tool. The leap of faith with actor models may perhaps never happen until it is made a part of Java platform itself (like how actors implementation is provided as part of the Scala standard library). For now, for die-hards Java nerds, I would suggest that among Java alternatives, Jetlang is the best because it provides a consistent model that does not feel misplaced or unnatural in the context of Java.

  7. Back to top

    Kilim - what's the matter here?

    by Bjorn Borg

    Kilim in my judgment is an attempt to misuse the purposes of a University in coming up with an offering to gain appeal with Java corporate world in the guise of academic research work. Hundreds of successful Java frameworks have been written during week-ends by great people through open source initiatives. Kilim can come no way close to them in terms of acceptance from the Java community. But unlike Kilim, none of them have got a PhD because they were willing to play by the moral rules of the game than go for fringe gains. You don’t need the paraphernalia of a University (professors, library, state grants …) to write a Java framework eh! Hope Universities see through this, if not they will be rendered inconsequential. For heaven’s sake, may Universities focus only on works which have larger impact on the society, bring real futuristic technologies that would make our generation proud!

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.