UseCase

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

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

• 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.