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

[Coleen Phillimore]

Hi John,

As Mandy said, we investigated using StackWalk API with MemberName for 
Throwable and the performance was *abysmal* and this performance impact 
would affect all applications, not just those explicitly using the 
StackWalk API.   The good news is that keeping our internal 
representation for Throwable.backtrace allows us to clean up the 
StackWalk API to use only MemberName and bci.

On 3/4/16 5:49 PM, John Rose wrote:
> On Mar 4, 2016, at 2:00 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> Footprint of MemberName as well as GC pressure (as they are kept as weak references in VM) are the performance concern that we will have to look at it in a future release.
> I hope we can increase our investment on MemberName as an all-purpose handle from Java to JVM metadata (like java.lang.Class).
> Specifically, the weak-pointer logic can probably be tuned to reduce overheads, at the cost of increased coupling between MemberName and the JVM.

I tried disabling the weak pointer logic for benchmarking and it was 
only a small portion of the overhead for throughput, but we didn't 
measure the cost to GC.

Coleen
>
> But the coupling is reasonable; we need something like that, and jlr.Method is way too heavy.
>
> — John