RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM
mandy.chung at oracle.com
Fri Mar 4 22:00:15 UTC 2016
> On Mar 4, 2016, at 10:42 AM, John Rose <john.r.rose at oracle.com> wrote:
> 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.
This is what StackWalker stores in StackFrameInfo per frame. I wish we could convert Throwable backtrace with the stack walker API.
Footprint of MemberName as well as GC pressure (as they are kept as weak references in VM) are the performance concern that we will have to look at it in a future release.
> – John
>> On Mar 4, 2016, at 5:28 AM, Aleksey Shipilev <aleksey.shipilev at 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:
>> 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