[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-core
Subject:    Fwd: Launching Ruby scripts and the future of MVM
From:       "Charles O Nutter" <headius () gmail ! com>
Date:       2006-02-23 22:05:57
Message-ID: fe35f8180602231405s4ea6e3ecpe1d03c5c4f540c78 () mail ! gmail ! com
[Download RAW message or body]

I wrote this email about a month ago, suggesting a core Kernel method
to launch Ruby scripts in a platform-independent way. I'm sure
everyone is very busy, but are there any thoughts on this? I'll
summarize what I'm hoping for:

- Many Ruby applications want to launch additional Ruby scripts.
- Currently they do that via Kernel.system or backquotes, which always
launch a new process. For example, many Rakefiles launch unit tests
this way.
- I believe there should be a method on Kernel to ask the interpreter
to launch a script for you, something akin to Kernel.run_script.
- On Ruby versions without multi-VM capability, this would simply call
Kernel.system with an appropriate Ruby executable.
- On Ruby versions with MVM, this could launch a new VM in the same
process to run the script.

In the JRuby world, where a new process means a new Java VM (something
we really want to avoid), we have to intercept calls to Kernel.system
and parse out the name of the Ruby (or JRuby) executable in order to
launch the requested script in the same process. If there were a core
method everyone used to launch external scripts, it would provide a
migration path to MVM on Ruby now and in the future.

I have also put this information into an RCR, #328. I will post these
thoughts to ruby-talk as well, and hopefully it will spur some
discussion. Thank you for your help!

- Charlie

---------- Forwarded message ----------
From: Charles O Nutter <headius@gmail.com>
Date: Jan 25, 2006 8:50 AM
Subject: Launching Ruby scripts and the future of MVM
To: ruby-core@ruby-lang.org


Hello again from the JRuby project!

It has come to our attention that there may need to be a standard way
to tell Ruby to launch a given script in a new interpreter engine.
Currently, it appears that many different approaches are used, ranging
from launching a separate process to forking and eval'ing a given
script. With the possibility of Ruby running in a multi-vm scenario
not far off (already possible today with JRuby and perhaps possible
soon in YARV) I believe it would be beneficial to have a way of
telling Ruby to "run this script in a new interpreter" and allow the
underlying ruby implementation to decide whether to launch a new
process or not. A potential method might be Kernel#run_script.

The issue we have with JRuby is that certain applications, Rake for
one, tend to want to launch subscripts in new Ruby interpreters. While
this is straightforward and relatively low-cost in the C Ruby world,
it incurs a severe performance and memory penalty in the JRuby world.
Launching a new "JRuby process" incurs the added pain of starting up a
new JVM process, not a trivial bit of work. This currently works as
expected, but is very slow and resource-intensive.

Perhaps it would be ideal if applications could call something like
Kernel#run_script, allowing the underlying Ruby implementation to
decide how to run that script. In today's 1.8 Ruby implementation,
that may simply mean running an external process, either by using
popen or system. In implementations like JRuby or YARV, the run_script
call could be handled by launching a new Ruby VM within the same
process, avoiding the process-startup penalty. It would allow us to
run some of the most complicated Rake scripts all in a single JVM
process with JRuby, utilizing our MVM capability very effectively.

What thoughts do you have? I know 1.8 is supposed to be pretty well
settled, but it sure would help us if this idea were implemented
sooner rather than later, so third-party apps could start using a
platform and implementation-independent mechanism for launching Ruby
scripts.

- Charlie



--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com


[prev in list] [next in list] [prev in thread] [next in thread]