Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trycatch blocks are being defined inefficiently in the JIT #3777

Closed
headius opened this issue Apr 2, 2016 · 0 comments
Closed

trycatch blocks are being defined inefficiently in the JIT #3777

headius opened this issue Apr 2, 2016 · 0 comments
Labels
Milestone

Comments

@headius
Copy link
Member

headius commented Apr 2, 2016

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 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.

@headius headius closed this as completed in ff882fc Apr 5, 2016
@headius headius added this to the JRuby 9.1.0.0 milestone Apr 5, 2016
@headius headius added the jit label Apr 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant