Originally posted in the comments to
Terracotta open sources JVM clustering, in response to Cameron Purdy's comment:
Terracotta can cluster two servers (one hot, one standby) while Tangosol can run a couple thousand servers as "hot" (active + active + active + etc) in an n-way fully-connected mesh (virtual channels). Our server throughput in a 100-server system is 50x ...
Ari made a great point in his
Google Tech Talk presentation about how when Java first came out it felt like a step backward in terms of memory management, but with HotSpot and some bake time it became much better than a developer can manage explicitly at code-time. He went on to say that VM-level clustering will eventually be that way.
One can argue about how much scale-up work the Terracotta hub needs
today, but it's hard to dispute Ari's basic premise: that (1) the JVM can transparently replicate objects by watching the GET_FIELD and PUT_FIELD bytecodes, and (2) that you can insure thread safety across a cluster the same way you would in a single VM, as long as you can meet the contract of the MONITOR_ENTRY and MONITOR_EXIT bytecodes.
If, in 5-10 years, it becomes as automatic as garbage collection is today, that is a huge ideological victory for Ari, Terracotta, and the KISS principle. I think they're on to something very big.
For example, from
Martin Fowler OOPSLA2005:
"While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said 'only 12 times faster than C means you haven't started optimizing'."
