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