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

[Aleksey Shipilev]

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