We are a BI platform that we distribute to our clients as a jar file
contains our web server. We develop in JRuby, then have a build process
that constructs a jar that bootstraps jruby, loads our ruby files (all
compiled to .class files), and runs a web server.
I’m trying to diagnose a crash bug that is taking down our web server,
in the process of checking out thread dumps I noticed something strange.
One aspect of our app is a scheduler that performs regular tasks. This
scheduler runs in its own ruby thread. What I’m confused about is the
difference between this thread’s dump between jruby and the jar.
This is jruby: gist:57e846985aae333c8a5c · GitHub
And this is jar with compiled jruby:
gist:e2149f9c2f1f1b87c06d · GitHub
This is not related to my crash bug (which deserves its own post), but I
found it peculiar that the thread dump varies when no other thread dump
does, and really the loading process from a java perspective is
the same. There may not be enough information here to know but…is this
In one stack trace there are some interpreter stack elements because
part of that code has not JIT’d yet to Java bytecode. In the other it
has. Is this expected? Possibly. You say in the .jar loaded one
you are pre-compiling all Ruby to .class files. So that explains why
that backtrace does not have interpreter frames in it. How do you run
in the other scenario? By default, we run in mixed mode and mostly
only compile once a method has been called enough. If you run -X+C,
then I bet you will see the same backtrace.
On Mon, Jan 28, 2013 at 1:11 PM, Ben Porterfield
[email protected] wrote:
runs in its own ruby thread. What I’m confused about is the difference
blog: http://blog.enebo.com twitter: tom_enebo
mail: [email protected]
Ah, that’s exactly right, we aren’t running compiled when we develop, we
are just running jruby with default args, that explains the difference.