Jruby-rack and --faster

Ruby JRuby
1

Came across the --faster option yesterday and decided to give it a try
because it sounded as if it would make things faster :-). I am using
trinidad to run a sinatra app and ran into an error with jruby-rack

org.jruby.rack.RackInitializationException: load error:
./lib/email_gateway – java.lang.ArrayIndexOutOfBoundsException: -1
from server.rb:148:in `start’

    at

org.jruby.rack.DefaultRackApplicationFactory$4.init(DefaultRackApplicationFactory.java:184)
at
org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:59)
at
org.jruby.rack.SharedRackApplicationFactory.init(SharedRackApplicationFactory.java:27)
at
org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:40)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4323)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4780)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:988)
at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:771)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:988)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:275)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:427)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:649)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:302)

Any idea why --faster would cause this? Should i even be using
–faster?

I am using jruby-1.5.3

thx.

-karl

2

Ah, --fast. Well, the reason why --fast is experimental is that it
broke some assumptions about regular Ruby code in order to optimize
it. Your code probably does not work under those assumptions.

Most of the optimizations are due to call-stack framing and integer
math IIRC, and I think we have some different, safer optimizations
queued up for those. So try out trunk and 1.6 when it comes out.

Cheers,
/Nick

3

So basically jruby 1.6 without the --faster should give about the same
optimizations?

Is it worth bringing up the issue with the --faster issue with the folks
at jruby-rack?

Thanks!

4

I can’t promise it will be exactly the same, but we’re working to bring
a similar class of optimizations to the 1.6 release (trunk does not have
them all by the way, they’re in the “backtrace” branch).

Also, I’m the “folks” at jruby-rack, so I’m aware of the issue now,
thanks.

/Nick

5

Wow you are busy. Is --fast something that should never be used in
production since it is experimental? Are you surprised that it does not
work with jruby-rack or is that to be expected?

Thanks for your help!

6

I wouldn’t recommend using --fast in production, and I’m not sure
Charlie would either. Maybe if the speedup was worth it and you’re
convinced your code doesn’t crash.

I’m not surprised that it doesn’t work with jruby-rack or a
full-fledged Ruby application.

/Nick