MagLev is the Ruby-ized version of one of the best object databases in the world. Keeping a running list of MagLev posts:

  • Avi Bryant - “I started off by describing MagLev as a “full stack Ruby implementation”, in the same way that Rails is a full stack web framework. To understand what I mean by that, see my earlier post on the Gemstone architecture: not only does MagLev provide a new (and fast) VM for Ruby, but it also provides an integrated shared memory object cache, and integrated transparent persistence.

    There’s no limit to what kinds of objects can be shared this way: procs and classes work just as well as arrays and strings. This isn’t RPC - the objects are copied into a shared cache when they’re created or modified, and if (but only if) another VM needs the object, it will pull it out of the cache and work on the local copy.

    Each VM has its own transaction state. When a VM enters a transaction, all of its changes are only locally visible until it is asked to commit.

    Because these shared objects are stored on disk, and are lazily loaded into the VMs only when needed, it means you can work with datasets that have many, many more objects than would fit into available RAM.”
  • Surprise of the Day - MagLev - “The Gemstone VM supports ACID transactions and will support some indexing functions to allow for fast data lookup. It became very obvious that the plan is to actually replace ActiveRecord in Rails and instead just use a huge persistent cached object store for data.”
  • The Even Bigger News about MagLev - The Maglev VM “does retain the ability to run Smalltalk code.” Ruby + Smalltalk + Gemstone is your secret nuclear weapon.
  • MagLev is Gemstone/S for Ruby, Huge News - “Avi Bryant seems to be leading the project and it’s only 100 days old (and how did it stay secret so long?!?) However, since it’s based on the mature Fast VM used by Gemstone/S, they’re already blowing away Ruby MRI 1.8 benchmarks with 8-60x speed increases. The shared memory cache (basically a large OODB) holds up to 17PB and has transactional capabilities and automatic synchronization.”
  • - Leave you email address for GemStone.
  • MagLev - GemStone build the Ruby - “What about Gemstone? As it happens, the architecture is exactly the same: there’s a single storage engine (called a “stone”), a memory cache on each server (the “shared page cache”), and any number of Smalltalk VM worker processes (“gems”). The gems handle the requests and run the code, and they stash objects in the page cache for speed and in the stone for persistence. The difference is, in Gemstone, these have all been designed from the ground up to work together as quickly and seamlessly as possible.”
  • Tom Dyer - “Portland homeless don’t care about MagLev, wtf!”
  • Stephen Bristol - “maglev is cool, closed source software”
  • Giles Bowkett - “@Croaky maglev is for-profit, closed source. contributing to the Ruby specs helps, though (and contributing to Rubinius probably also).”
  • Nathan Weizenbaum - Having a closed-source Ruby VM, even (especially?) a really good one, makes me nervous
  • InfoQ - “In essence, MagLev was filling the roles not just of the VM but also the caching and persistent storage layers.”
  • MagLev, JRuby, And Rubinius: Who Will Win? - “[The software community] again ignoring the importance of the ecosystem and fixating on the useless question of who will be the dominant player… Nobody’s going to ask if Ruby is enterprise-ready when they see that it runs on the same rock-solid system which has powered a gigantor JP Morgan financial application for decades… It’s very likely you’ll see Rubinus, JRuby, and RubySpec patches resulting from MagLev, because open source enriches the ecosystem. It seems highly likely that MagLev will be able to leverage Rubinius code. Not only that, but the Smalltalk world already has an open source alternative to Gemstone.”