Doing more on the Java side means it will be easier generate strings lazily, only if the exception actually prints or presents STEs.
All we need to store eagerly per frame is a MemberName and a BCI. – John > On Mar 4, 2016, at 5:28 AM, Aleksey Shipilev <aleksey.shipi...@oracle.com> > 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. > > 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 > >
