Lambda the Ultimate

I was psyched by the title, since message based comms seem the way to go, as Erlang demonstrates (and the paper nods at Erlang). But I spent no more than three minutes scanning text, looking for the novel part; I found it in the concluding section 8, whose first two sentences are cited below for folks who want a fast look:

8. Conclusion To our knowledge, this work is the first to integrate a full-fledged garbage-collected language with statically verified channel contracts and safe zero-copy passing of memory blocks. The main novelty of the work is the enabling of simple and efficient implementation techniques for channel communication due to the system-wide invariants guaranteed by the static verification.

This explains why I didn't stop and read middle parts more slowly, since it looked fairly conventional in memory management for message passing. (It's all in wrists ...I mean, all in heap definition.) The static verification part kills it for me — my interest in types ends with adding minimal optional typing to dynamic languages. I'd find novelty in fun memory management. Maybe it's hard to find new ground there — at least without doing something rather complex, which is its own punishment.

However, emphasis is well placed on integrating message passing at the language level — as opposed to just in complex add-on libraries. Even so, I had trouble seeing async based message APIs, which I think are more important than synchronous APIs. Did I just miss them? Or doesn't this paper care about async? Oh, I see; now that I search, I find "async" only appears under keywords on the first page, and under future work in the conclusion.

neelk wrote "... eliminate the use of hardware memory protection and context switches ...
Which they've labeled "the Unsafe Code Tax"

(section 4.2.1 Singularity: Rethinking the Software Stack April 2007 pdf )

neelk: First, they want different processes to be able to use entirely different garbage collectors.

Awesome! No I mean it: that's a cool idea, and respectable when it hints at possibly allowing non-lockin solutions in other processes. (Of course, they might still plan to write all garbage collectors in other processes, forcing withdrawn respect.) Being able to separate things that needn't be tied together is very helpful in many things, since substitution is a basic diagnostic tool.

Desire to cut costs is a given, and touching memory is a major cost in recent years when memory latency hasn't decreased as fast as clock cycles increased. So pass-by-reference becomes a bigger payoff, even though sharing causes headaches. However, if shared space is immutable, then you can't tell it's shared, and even code running in the same physical process can't tell sharing happens in different logical processes. (I've talked about this before, but not very clearly.)

Just because they're solving completely predictable problems doesn't mean it's not hard. Memory management is a pain. I was just planning to mark memory immutable, and let processes blow themselves up if they tried to modify immutable state. (This is a kind of "kill them all and let the coder sort them out" design style, putting the burden of eventually meeting constraints on the programmer, rather than forcing the OS to protect itself from predations of coders.)

In the conclusion:

To our knowledge, this work is the first to integrate a full-fledged garbage-collected language with statically verified channel contracts and safe zero-copy passing of memory blocks.

However, I do not see any details about the statically verified channel contracts. The only thing I saw was:

Send methods never block and only fail if the endpoint is in a state in the conversation where the message cannot be sent.

...which would be a runtime check, not a static check. That statement leads me to believe that the channel contracts do not offer any stronger guarantees than any other IDL compiler-like system.

Furthermore, I do not see a big deal with multiple garbage collectors here---there is one per process, the same as any other system, and a manually-allocated global heap for message storage. That the performance of IPC is better than on systems that do have to cross VM boundaries is unsurprising, but that was the point of an earlier paper, if I remember correctly.

The future work also describes:

We are also developing extensions to the channel contracts that enable static prevention of deadlock in the communication of processes.

...which would be neat, but not terribly so since their channel contracts are basic state machines.