AW: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Bernd Eckenfels ecki at
Sat Mar 12 09:21:56 UTC 2016


Regarding “exceptional”:
Speeding up stack-walking can greatly help log&trace frameworks (when they are configured to log the callsite). They hopefully do not use Throwables anymore, but I guess the other variants to get the stack traces of the last few frames on the stack still benefit from your idea.


>From Win 10 Mobime

Von: Aleksey Shipilev
Gesendet: Samstag, 12. März 2016 02:32
An: Coleen Phillimore; hotspot-runtime-dev; core-libs-dev
Betreff: Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 03/12/2016 02:49 AM, Coleen Phillimore wrote:
> On 3/11/16 6:36 PM, Aleksey Shipilev wrote:
>> On 03/08/2016 01:55 AM, Coleen Phillimore wrote:
>>>> Aside: see the last experiment, avoiding StringTable::intern (shows in
>>>> profiles a lot!) trims down construction costs down even further. I'd
>>>> think that is a worthwhile improvement to consider.
>>> Hm, this is an interesting experiment.  I've been looking for a better
>>> way to store the name of the method rather than cpref.
>> I did some preliminary work for storing class names (those are easy,
>> since is already there on Java side). Would be nice to handle
>> both method names and source files, because we are looking at some nice
>> improvements:
>> Can you pick it up, and follow up further?
> Yes, I think caching String classname on Class<?> might be also helpful
> for the StackWalk API.
> My impression was that the performance of Throwable.getStackTrace()
> wasn't super critical since it's used in exceptional conditions. Let me
> know otherwise.

While we keep our guidance at "beware of using Exceptions frequently",
we should not avoid easy fixes that make them less painful. Granted,
projects that conscientiously use Exceptions for e.g. non-local returns
have learned to nop out fillInStackTrace(). But it would be nice to
alleviate the pain for those who overlook that, or have no choice
needing the actual stack trace.

(Even used on non-critical paths, CPU time spent dealing with Exceptions
worldwide is better spent elsewhere; it would be an eco-friendly fix to
do :)).


More information about the core-libs-dev mailing list