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
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.
The text was updated successfully, but these errors were encountered:
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 implicitStandardError
in blank rescues.Risks:
===
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.
The text was updated successfully, but these errors were encountered: