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

[Coleen Phillimore]

Hi Aleksey,  This is an interesting experiment.

On 3/4/16 8:28 AM, Aleksey Shipilev wrote:
> On 03/02/2016 11:21 PM, Aleksey Shipilev wrote:
>> On 03/02/2016 10:57 PM, Coleen Phillimore wrote:
>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote:
>>>> Is there an underlying reason why we can't return the pre-filled
>>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin
>>>> with? This will avoid leaking StackTraceElement constructor into
>>>> standard library, *and* allows to make StackTraceElement fields final.
>>>> Taking stuff back from the standard library is hard, if not impossible,
>>>> so we better expose as little as possible.
>>> We measured that it's faster to allocate the StackTraceElement array
>>> in Java and it seems cleaner to the Java guys. It came from similar
>>> code we've been prototyping for StackFrameInfo.
>> OK, it's not perfectly clean from implementation standpoint, but this
>> RFE might not be the best opportunity to polish that. At least make
>> StackTraceElement constructor private (better), or package-private
>> (acceptable), and then we are good to go.
> Okay, here's a little exploration:
>    http://cr.openjdk.java.net/~shade/8150778/StackTraceBench.java
>
> The difference between allocating in Java code, and allocating on VM
> side is marginal on my machine, but I think we are down to native memset
> performance when allocating on VM side. Therefore, I'd probably stay
> with Java allocation which codegen we absolutely control.

Thanks for the experiment.  We measured a greater performance 
difference.  The theory is that through Java, allocation is a TLAB 
pointer update in most cases, vs going through all the C++ code to do 
allocation.  The small difference for performance here isn't critical, 
but having the allocation in Java looks nicer to the Java programmers here.
> 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.

thanks,
Coleen
>
> Cheers,
> -Aleksey
>
>