On 07/08/2012 12:50 AM, Charles Oliver Nutter wrote: > On Saturday, July 7, 2012, Rémi Forax wrote: > > You can use Throwable.getStackTraceElement() > which is package visible and OpenJDK specific but at least > it will be faster for all VMs that uses OpenJDK. > > I'll certainly explore that to see if it improves the situation. If > it's faster, it might be a way out in some circumstances. > > It seems like an official public API is needed here... > > Please never optimize warnings, they are here to bug users > > until they fix the thing. So they should be slow :) > > > Yes, except when *everyone else* has faster warnings than you. Then > you're just giving people another reason to not use your stuff. > > Granted, JRuby is now becoming far and away the fastest Ruby > implementation for exactly the reasons that stack traces are slow, but > often making 90% of the code 5x faster but 10% of the code 100x slower > means people give up on you without bothering. > > Remember, I agree with you...but I also feel like this attitude has > allowed stack trace generation to avoid optimization effort for a long > time, and there *are* useful things you can do with an introspectable > call stack.
Throwable.getStackTraceElement() let you walk the stack trace without generating the whole stack trace, in my opinion it's enough. BTW, I also think you are responsible too for the cost of generating stacktraces because the cost depends on the size of the stacktrace and an AST interpreter is a big consumer of stack frames. I am guilty too, PHP.reboot has the same issue and I try to mitigate that by avoiding to have an helper methods in the stacktrace of calls (not that easy without tailcall). > > - Charlie Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
