RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Aleksey Shipilev]

On 03/03/2016 07:13 AM, David Holmes wrote:
> On 3/03/2016 1:11 PM, Coleen Phillimore wrote:
>> On 3/2/16 9:29 PM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> On 3/03/2016 10:03 AM, Coleen Phillimore wrote:
>>>> Freshly tested changes with jck tests, with missing checks and other
>>>> changes to use the depth field, as pointed out by Aleksey.  I've kept
>>>> the StackTraceElement[] allocation in Java to match the new API that
>>>> was
>>>> approved.
>>>
>>> I would have argued for returning a constructed array instead but if
>>> that decision has already been made then it has already been made.
>>
>> I see Mandy's reply afterward, but it's really an opinion question and I
>> don't think there's a strong technical or correctness reason to do it
>> one way rather than the other.  The preference is to write most code in
>> Java and it is faster to allocate these in Java.  But this isn't a
>> critical path for performance, it just helps.
> 
> I'm not sure how it can be faster to allocate in Java when the VM does
> the allocation anyway ?? It is certainly easier to write the array
> initialization code in the Java. The ugly part of doing it in Java is
> that the VM has to poke the right length into the depth field. From an
> API design perspective it is cleaner for the called function to allocate
> exactly the size and type of array needed rather than having to
> communicate that information out, and then add checks to make sure a
> different sized (or typed) array is not passed in.

I think if you we don't want to revisit this in future, we need to
explore the VM angle on this. Do we know if we can speed up VM array
allocation enough to make a cleaner API for this feature? I can help
with this, but not today.

Thanks,
-Aleksey