The best talk I’ve been to so far is TerraCotta‘s introduction and patterns. Ari is a good speaker with passion, intensity and speed that I admire (though some others might find the talk a bit too informative).
I’ve heard about TerraCotta before, but this was the first time I got to know the details. The basic functionality that they claim is transparently clustering your objects, so that all changes on one JVM are visible in all the rest.
Turns out they instrument GETFIELD/PUTFIELD instructions and propagate updates among the servers. It is easy enough to do for the basic types and they have special support for strings and collections, but they also need to assign identities to objects so that updates to reference fields would change only the reference to an object with the same identity. For that they instrument constructors to associate identities with objects and reconstruct identical graphs on different JVMs. Of course, like JavaRebel, they also need to instrument reflection.
In addition to that they instrument MONITORENTER/MONITOREXIT instructions to acquire distributed locks instead of local ones. There are some quirks here that I’d be interested in finding out, e.g. how do they deal with locking the same monitor in the code not managed by TerraCotta. The likely answer is that they don’t :)
An interesting question to ask here is whether we could use STM. Basically TerraCotta needs to collect changes to the objects anyway, so to enable optimistic locking instead of pessimistic they’d have to add two things:
- A way to revert changes done to objects. A pretty trivial thing to do.
- A way to unwind the stack if the commit does not succeed. This is not easy, but can be done with an approach like Geert Bevin used to implement continuations.
There is also a question of what to do when the critical block does global side-effects. IMHO you can just delegate this to the user, so that he has to explicitly enable optimistic locking at a particular spot.
In fact when I think about it, this approach would make some sense even without distributivity. For highly concurrent code such optimistic concurrency would create a great performance win (as indicated by Azul). Of course you have to trade it off with the instrumentation costs, but for some applications the performance win might be tremendous.
When I asked Ari about optimistic locking he indicated that they have some experimental support in the works, but there are still some problems to overcome.
Tags: bytecode, java, qcon, terracotta