RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM
aleksey.shipilev at oracle.com
Fri Mar 4 13:28:19 UTC 2016
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:
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.
More information about the core-libs-dev