Hello, 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.
Bernd Gruss Bernd -- http://bernd.eckenfels.net >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 Class.name 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: >> https://bugs.openjdk.java.net/browse/JDK-8151751 >> >> 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 :)). Thanks, -Aleksey
