Re: [jruby-user] Anything wrong with shelling out to jruby?

Ted Han <[email protected]> Tue, 17 Mar 2015 09:10:31 -0400
Newsgroups gmane.comp.lang.jruby.user
Message-ID <CALhFOHkqyXiwv3jPk16qx7tJfUHCvYAsT+bfnS7wSpHRXp8i1Q@mail.gmail.com>
There's a section about this in the jruby wiki:
https://github.com/jruby/jruby/wiki/Improving-startup-time#running-sub-rubies-in-the-same-jvm

On Tue, Mar 17, 2015 at 9:07 AM, Keith Bennett <[email protected]>
wrote:

> I don’t know of any problems shelling out to JRuby, but it will require
> the memory and startup time of starting a whole new JVM for each time you
> do.  I would not be comforted by the fact that the OS might save your first
> JVM’s RAM to disk and restore it later; that would take time.  Is speed not
> important in your case?
>
> If I were you, I’d look at minimum to shelling out once rather than a
> dozen times.  Why do you want to shell out so many times?
>
> Also, your script looks like it shells out only once, no?
>
> - Keith
>
> > On Mar 16, 2015, at 6:45 PM, John Joseph Bachir <
> [email protected]> wrote:
> >
> > I have an application where I would like to shell out to jruby. A very
> simple script that essentially does this a dozen times serially:
> >
> > begin
> >   `rails runner scripts/foo.rb`
> > rescue
> >   # .. report error
> > end
> >
> > I remember hearing about problems invoking jruby from jruby. Some
> initial basic tests in my dev environment don't show any problems.
> >
> > My guess at what the problem is: if jruby is configured to take an
> application's worth of RAM (say 512M), then the small out script will take
> that and then each individual sub process will take that as well.
> >
> > I wonder if in practice this won't matter much, because the OS will move
> most of the outer instance's memory into VM and just keep it there?
> >
> > Thanks for any insights or pointers to other info about this!
> >
> > John
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>