BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News NoSQL OODB with Smalltalk-based Ruby VM: MagLev 1.0 Released

NoSQL OODB with Smalltalk-based Ruby VM: MagLev 1.0 Released

This item in japanese

Bookmarks

MagLev 1.0 has been released: MagLev is a Ruby VM built on GemStone/S, a 64 bit Smalltalk VM. But MagLev is much more than a Ruby VM, it comes with a mature NoSQL data store, from the website:

MagLev VM takes full advantage of GemStone/S JIT to native code performance, distributed shared cache, fully ACID transactions, and enterprise class NoSQL data management capabilities to provide a robust and durable programming platform. It can transparently manage a much larger amount (terabytes) of data and code than will fit in memory.

InfoQ caught up with Monty Williams of VMWare (GemStone was bought by VMWare) to talk about MagLev 1.0.

InfoQ: Where does MagLev fit in the current NoSQL spectrum?

  • I don't think of MagLev only as a Ruby VM that has an integrated NoSQL database. I think of MagLev as a NoSQL database that uses Ruby for its data manipulation language.
  • The one thing I don't think people have wrapped their heads around is MagLev provides a "single object space". Nothing has to be sent/retrieved to/from a separate DB. All your code is executed "in the database." You don't even need to keep track of which objects have been modified so you can flush them to disk. MagLev handles that automatically. 
  • You can store any Ruby object, even procs, lambdas, threads, continuations. Here is an example of stopping, copying, saving, and restarting Threads in a different VM than they originated in. http://blog.bithug.org/2011/09/maglev-debug
  • MagLev persistence is akin to Image Persistence, i.e. objects are persisted to disk in the same format they are in shared cache. You don't need to marshal them or convert them to JSON or another format.
  • MagLev transactions are ACID, which means that multiple VM's can interact with the same repository and share state, objects, and code while maintaining referential integrity.
  • When you start a new MagLev VM, code loaded by another VM is likely to still be in the cache. So loading/requiring it can be quite fast.

InfoQ: Is there support for MagLev on VMWare's Cloud offerings?

Not at present. We prototyped it back in August, and would like to see it happen, but it depends on demand.

InfoQ: What's the Ruby language support status, 1.8.7? What's the plan for 1.9?

1.8.7 for now, since that's the most stable platform. 1.9 was too much of a moving target to get it into 1.0. Whether we do 1.9 also depends on demand.

InfoQ: Is there any FFI or native extension support?

Both FFI and native extension support are built in. Neither will run everything MRI does. MagLev has a memory-compacting GC, which requires native code to be somewhat "well behaved". The restrictions and how to work around them are described in https://github.com/MagLev/maglev/blob/master/lib/ruby/1.8/include/Maglev_c_extensions.md.

InfoQ: What's the threading/concurrency story for MagLev?

MagLev uses green threads. However, MagLev has a shared, transactional object space, so there is a scalable built-in model for parallelism across MagLev VMs. Since *all* connected MagLev VMs see the same objects, MagLev can have thousands of truly parallel threads running on the same pile of objects.

InfoQ: MagLev uses the MIT license, what's the licensing situation for the underlying GemStone/S VM?

Just to clarify, the Ruby and Smalltalk code we wrote for MagLev is MIT licensed. The Ruby Library and other Open Source components we used are licensed differently. See https://github.com/MagLev/maglev/tree/master/Licenses (esp. the README.)

InfoQ: Is there a limited free version and a commercial version of MagLev or are all free of charge?

There will always be a free version. The only limit is a 2GB shared cache, e.g. https://github.com/MagLev/maglev/blob/master/etc/maglev.demo.key-Linux-x86_64.
It doesn't limit the amount of data you can store, only the amount that can be cached in shared memory.

InfoQ: In short: If I use Maglev, will I have to pay: never, sometimes, always?

You only need to pay if you want support, or you want more cache.

InfoQ: How does MagLev relate to your Smalltalk and Seaside solutions?

Both use the same JIT, bytecode loop, cache, and persistence provided by GemStone/S. The underlying VM will run both Ruby and Smalltalk code so you can also run Seaside on a MagLev VM.

Installing MagLev is simple with rvm:

rvm install maglev
rvm use maglev

For more info see the "Get Started with MagLev": document and the linked documentation. The Examples section contains sample code showing MagLev's support for frameworks like Sinatra or Rails 3.1. 

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT