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

[Aleksey Shipilev]

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.

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.

Cheers,
-Aleksey