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 core-libs-dev mailing list