Truffle omit backtraces #3637
Truffle omit backtraces #3637
Conversation
…deEffectFree." This reverts commit acf9d27.
|
Found a transfer in the wrong place and added an explode loop, which reduced us to 0.02 s. Still don't know why it's an order of magnitude slower than JRuby. Needs investigation at some point. |
|
@enebo tells me in JRuby they re-use a single instance of the exception when doing the omitted version. We allocate and escape a new instance every time. |
|
Graal is no better than jruby+truffle when it comes to eliding backtraces ;), so (without benching) maybe this will help: // in public class RaiseException extends RuntimeException
public final Throwable fillInStackTrace() {
return null;
} |
|
@thedarkone huh... I didn't know we didn't already do that... we do in our That was indeed the problem - we're now 10x on JRuby (I had to change the number of iterations to 100k to make it visible). Thanks! |
|
Cheers |
|
👍 Nice work Chris.
We do use preallocated exceptions for a few that never have backtracked
(like for "expected" exception like EAGAIN) but I think we still allocate
and throw new exceptions for the backtrace-elided stuff. @enebo could
confirm since he did most of that work.
I hope Truffle will be able to do something about the the deoptimization
for backtraces, because there are still a lot of bad libraries out there
that use normal exceptions as flow control. They're so cheap on cruby that
it doesn't affect most people but its obviously terrible for us and worse
for truffle.
|
|
@chrisseaton sorry I made an ass of u and me since I had assumed you have replaced fillInBacktrace. Although a single instance in theory I think should have also partially addressed that since fillInBacktrace should only get called once. |
Omit backtraces when we think they can't be used, as JRuby IR does. Obviously not going to work for someone looking for the exception by
ObjectSpacebut I think that's the only edge case and you really would have to try very hard to tigger it. Could also upset some debugger stuff? At worst, we can give a nice error message that they'll see and will tell them how to turn it off.Note the tiny number of iterations. On MRI runs in 0.00117 s, JRuby 0.001 s, JRuby+Truffle+Graal before the optimisation 0.469 s. With the optimisation 0.07 s.
We still have two bad problems: first, there is still some huge cost somewhere with exceptions we don't know about, which has nothing to do with
iterateFramesas with the optimisation we don't call that. Secondly, when we actually create a backtrace it's crazy - we materialise all frames in order to get the method object for printing the backtrace.@nirvdrum @eregon @pitr-ch @headius @thedarkone