RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM
Coleen Phillimore
coleen.phillimore at oracle.com
Wed Mar 2 20:36:27 UTC 2016
On 3/2/16 3: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.
Well, the RFE is intended to clean this up but I don't think there's
agreement about what the cleanest thing is. If the cleaner API is:
StackTraceElement[] getStackTraceElements();
we should change it once and not twice. I'd like to hear other opinions!
Since StackTraceElement constructor is called by Throwable it has to be
package private but can't be private. I have made it package private.
>
> Also, I think you can drop this line:
> 836 int depth = getStackTraceDepth();
Oh, right, I can do that. I was hiding the field depth. i don't need
the function either.
Thanks! Thank you for looking at this so quickly.
Coleen
>
> Thanks,
> -Aleksey
>
More information about the hotspot-runtime-dev
mailing list