jit failure: rack #4255
Oct 30, 2016
Neat. Guess we need better handling for errors during JIT prep, as well as more robust name-mangling code.
Oct 30, 2016
I have pushed better exception-handling in 35f4547, but I have not been able to reproduce locally. Can you try to run this again with a JRuby master build, adding some logging into rack/lib/builder.rb:55 to see where that block is coming from?
Nov 2, 2016
with master build i'm seeing a new compile error:
and this one:
other methods keep getting jitted on startup, even after these errors get raised
i tried overriding
any tips on how to add logging without getting in the way of startup jitting?
fyi my rails app uses the following rack middleware:
the prometheus middleware comes from
i've seen some errors in production related to the prometheus exporter. this is a bit of a wild guess, but you may be able to reproduce locally by configuring your rails app likewise
Nov 8, 2016
Ok, let's look at the errors you have now.
This one is expected. We currently have fairly conservative size limits for jitting code to JVM bytecode, since too-large code will remain in the JVM's interpreter, running slower than our interpreters.
This one is a real problem that should be filed separately and fixed. It relates to one of our optimization passes in JRuby's compiler. Shouldn't be hard to fix. cc @subbuss @enebo
This also looks like a problem with how we generate the "caller" backtrace. Judging by the line number indicated, it looks like something from the original Java stack trace element is null and we're not guarding for that. I can make a quick fix for this.
So, please file the second item above as a separate issue and I'll fix the remaining "caller" problem.
config.features = %w(gemjar runnable executable)
config.override_gem_home = true
methods should get jitted on startup
many methods get jitted, then:
the error seems to halt startup jitting altogether
The text was updated successfully, but these errors were encountered: