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

Improve backtrace elision #4551

Open
headius opened this issue Mar 28, 2017 · 1 comment
Open

Improve backtrace elision #4551

headius opened this issue Mar 28, 2017 · 1 comment

Comments

@headius
Copy link
Member

headius commented Mar 28, 2017

For #4540 we investigated a performance regression that turned out to be our more-strict (i.e. less broken) backtrace elision in JRuby 9.1.8.0.

Our recommendation for that bug was to fix the excessive exception raising in the libraries in question, but this bug will track improvements to backtrace elision.

The current thought is that we could, for some subset of rescue clauses, scan the rescue arguments before entering the rescued body. That would allow is to see if the rescued elements are normal exceptions with normal === implementations, allowing us to perform the same backtrace elision as we do for the implicit StandardError in blank rescues.

Risks:

  • If the exception looked up before the block is different than what the rescue clause would see later, we may elide incorrectly.
  • If the exception is the same but the === impl changes, we may elide incorrectly.

These risks could be mitigated (but not eliminated) by deferring the decision about backtrace elision to the last possible moment: immediately before generating a stack trace. Then the failure surface becomes the period between that decision and the eventual rescue of the exception -- a very short period of time while the stack is unwound. If ensures or other rescues would intervene, we'd already have disabled the elision...so this would only affect the logic triggered by the rescue argument itself and any out-of-band activity (e.g. on another thread).

This would be good to have for 9.2 but landed sooner for bake time.

@headius
Copy link
Member Author

headius commented May 16, 2018

This is not on any roadmap and mostly represents a napkin-drawing of how we might improve our backtrace elision. I'm removing it from any milestone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant