Improving the performance of stacktrace generation

[Charles Oliver Nutter]

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.

- Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120707/344fdd9d/attachment.html