Some pass used by JIT produces code that no longer works in interpreter

[headius]

We talked about this yesterday...when the JIT fails, it does so after it has already run additional passes against the same IR that we would be interpreting. Something in these passes causes that IR to break for the case below when it fails to compile ReceiveKeywordRestArg.

2014-09-25T07:14:08.833-05:00: JITCompiler: could not compile:Open3.Open3.Open3 at /Users/headius/projects/jruby/lib/ruby/2.1/open3.rb:29 because of: "ReceiveKeywordRestArgInstr has no compile logic"
LoadError: load error: open3 -- java.lang.RuntimeException: Should not get here!
     require at org/jruby/RubyKernel.java:926
  __script__ at /Users/headius/projects/jruby/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:55
      (root) at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/rake-10.3.2/lib/rake/cpu_counter.rb:4
     require at org/jruby/RubyKernel.java:926
  __script__ at /Users/headius/projects/jruby/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:55
      (root) at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/rake-10.3.2/lib/rake.rb:1
     require at org/jruby/RubyKernel.java:926
  __script__ at /Users/headius/projects/jruby/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:55
      (root) at /Users/headius/projects/jruby/lib/ruby/gems/shared/gems/rake-10.3.2/lib/rake.rb:48
        load at org/jruby/RubyKernel.java:941
  __script__ at /Users/headius/projects/jruby/bin/rake:23

To triger this again, here's the command line I used. You'll want to run it on JRuby prior to a commit I'm about to make that fixes this instr in the JIT.

jruby -Xjit.threshold=0 -Xcompile.invokedynamic=true -Xjit.logging=true -S rake -T

Or you can probably just add the JIT passes to the interpreter passes and try requiring "open3.rb".

cc @subbuss @enebo

[headius]

The keyrest fix is in 6f40ed6.

[headius]

We now clone the instructions for interpreter so the JIT does not affect it. We know we have to keep it that way for thread-safety and other reasons, so I'm going to call this fixed.

The general case -- that passes should always produce code that can be jitted or interpreted -- is known to us and when we have specific cases we'll fix them.