JRuby

Compiler failure compiling rulexer.rb in rubylexer

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: JRuby 1.6.7
  • Component/s: Compiler
  • Labels:
    None
  • Number of attachments :
    0

Description

Have not narrowed this down yet:

could not compile: /Users/headius/projects/jruby/lib/ruby/gems/1.8/gems/rubylexer-0.7.2/lib/rubylexer/rulexer.rb because of: "1"
java.lang.ArrayIndexOutOfBoundsException: 1
	at jruby.objectweb.asm.Frame.a(Unknown Source)
	at jruby.objectweb.asm.Frame.a(Unknown Source)
	at jruby.objectweb.asm.MethodWriter.visitMaxs(Unknown Source)
	at org.jruby.compiler.impl.SkinnyMethodAdapter.end(SkinnyMethodAdapter.java:499)
	at org.jruby.compiler.impl.MethodBodyCompiler.endBody(MethodBodyCompiler.java:97)
	at org.jruby.compiler.impl.BaseBodyCompiler.defineNewMethod(BaseBodyCompiler.java:2147)
	at org.jruby.compiler.ASTCompiler.compileDefn(ASTCompiler.java:1732)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

Ok, it's a stack management problem. Here's a reduced case:

while true
  puts (false or break)
end

The problem here is that the break (a simple jump in this case) occurs when there's state on the stack (preparation for the puts call). So the break jump jumps to a point in the stack which doesn't expect to have that stuff on the stack, and so there's an inconsistency which the bytecode validator picks up.

The fix for this, I believe, would be to detect when "break" is being used as an expression and fall back on the exception-based flow control. It's not a trivial fix at the moment, unfortunately.

Show
Charles Oliver Nutter added a comment - Ok, it's a stack management problem. Here's a reduced case: while true puts (false or break) end The problem here is that the break (a simple jump in this case) occurs when there's state on the stack (preparation for the puts call). So the break jump jumps to a point in the stack which doesn't expect to have that stuff on the stack, and so there's an inconsistency which the bytecode validator picks up. The fix for this, I believe, would be to detect when "break" is being used as an expression and fall back on the exception-based flow control. It's not a trivial fix at the moment, unfortunately.
Hide
Permalink
Charles Oliver Nutter added a comment -

I took a few minutes to look into this and it's still pretty hard to resolve.

Because we try to optimize simple while loops to have no exception handling, there's no easy way to support this. If we modified it to simply use exception handling for the break, there would be nothing to catch it. So we need a better way to examine the entire contents of the while loop to know whether it can be optimized to a simple loop with no exception handling. I have been stalling on coming up with a better mechanism for inspecting and optimizing the AST, and this may have to come after 1.2.

Show
Charles Oliver Nutter added a comment - I took a few minutes to look into this and it's still pretty hard to resolve. Because we try to optimize simple while loops to have no exception handling, there's no easy way to support this. If we modified it to simply use exception handling for the break, there would be nothing to catch it. So we need a better way to examine the entire contents of the while loop to know whether it can be optimized to a simple loop with no exception handling. I have been stalling on coming up with a better mechanism for inspecting and optimizing the AST, and this may have to come after 1.2.
Hide
Permalink
Diego Plentz added a comment -

Charles, your example is working here in jruby 1.6.7 in both 1.8 and 1.9 modes. Can be closed I think.

Show
Diego Plentz added a comment - Charles, your example is working here in jruby 1.6.7 in both 1.8 and 1.9 modes. Can be closed I think.
Hide
Permalink
Charles Oliver Nutter added a comment -

Calling it fixed in 1.6.7, as reported.

Show
Charles Oliver Nutter added a comment - Calling it fixed in 1.6.7, as reported.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Charles Oliver Nutter
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: