You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All JRuby 9k versions up through current master (9.1).
Expected Behavior
We use exception handling in Ruby IR for dealing with missing methods and constants, defined?, frame and variable scope management. In general, most of this handling only occurs along method boundaries, routing logic to a per-method rescue block to clean up execution state. The try/catch tables in bytecode should reflect this.
Actual Behavior
Currently the JIT defines a trycatch in bytecode for each basic block that has an associated rescue block (including the global ensure block). This means that if a method has N basic blocks and a global ensure block, we will emit N trycatch into the bytecode. This may interfere with the JVM's optimizations, since according to several comments in this SO post the JVM can't optimize or reorder code across exception-handling boundaries: http://stackoverflow.com/a/16452100/152946
This needs confirmation, but more efficiently defining the trycatch blocks would still have value in reducing the complexity of the emitted bytecode.
The text was updated successfully, but these errors were encountered:
Environment
All JRuby 9k versions up through current master (9.1).
Expected Behavior
We use exception handling in Ruby IR for dealing with missing methods and constants,
defined?
, frame and variable scope management. In general, most of this handling only occurs along method boundaries, routing logic to a per-method rescue block to clean up execution state. The try/catch tables in bytecode should reflect this.Actual Behavior
Currently the JIT defines a
trycatch
in bytecode for each basic block that has an associated rescue block (including the global ensure block). This means that if a method has N basic blocks and a global ensure block, we will emit Ntrycatch
into the bytecode. This may interfere with the JVM's optimizations, since according to several comments in this SO post the JVM can't optimize or reorder code across exception-handling boundaries: http://stackoverflow.com/a/16452100/152946This needs confirmation, but more efficiently defining the trycatch blocks would still have value in reducing the complexity of the emitted bytecode.
The text was updated successfully, but these errors were encountered: