1 application with N VMs
- 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
- 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.