RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM
coleen.phillimore at oracle.com
Mon Mar 7 22:55:43 UTC 2016
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:
> 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.
More information about the core-libs-dev