UseCase

1 application with N VMs

  • sandbox
  • separate namespace
  • parallelization without synchronization (CRuby/Rubinius)
  • slow or expensive launching of "ruby" subprocesses (JRuby, as in system('jruby -e ...'))

N applications with N VMs

  • mod_ruby
    • also webrick?
  • application embedded ruby
    • ex) editor, each buffer has separated VM

M applications with N VMs

  • mixed model
  • existing "large process" service models (JRuby, hosting many apps in a single app server)
  • dynamic scaling of concurrent capabilities across M applications (Rails single-threaded nature)

It seems thread model....

CON: Threading plays heavily into this. JRuby does not need MVM for concurrency, but does for namespace and to avoid launching a new JVM. Ruby in general on a single processor doesn't need MVM for performance but still needs it for single-threaded frameworks like Rails. Performance and scaling requirements should be considered separately from functional requirements; they address different areas and are largely orthogonal.

Last modified: 2008-01-29