Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

[Jörn Huxhorn]

On 20. September 2013 at 12:06:42, Remi Forax (forax at univ-mlv.fr) wrote:
On 09/20/2013 11:57 AM, Jörn Huxhorn wrote: 
> On 20. September 2013 at 11:35:24, Peter Levart (peter.levart at gmail.com) wrote: 
> On 09/20/2013 10:57 AM, Jochen Theodorou wrote: 
>> Am 20.09.2013 09:28, schrieb Nick Williams: 
>> [...] 
>>> This is all well and good, but some of us just need a simple array. 
>>> This seems like over-engineering. I just want an array of 
>>> StackFrameInfos/StackTraceFrames. 
>> 
>> if you need the full stack, then misusing a Predicate and a dummy 
>> Consumer to collect everything looks a lot like not intended use. The 
>> intended inability of lambdas to write to local variables outside the 
>> lambda is not helping here to avoid anonymous inner classes. So what 
>> was a simple method call, will look really awful - I agree. 
> List<StackFrameInfo> frames = new ArrayList<>(); 
> Thread.walkStack(frames::add); 
> 
> No so awfull. 
> 
> Regards, Peter 
> This is precisely what I mean. Yes, it has a nice syntax but it will perform worse than simply working on a StackTraceFrame[]. 

why ? 

> 
> It's not that awful but it's the construction of an additional ArrayList instance and n additional method calls plus additional gc heat. 
> 
> We are talking about code that will be executed for every single log statement, i.e. millions/billions of times. This *will* add up and it *will* make a significant difference. This isn't premature optimization either - it's just a very hot hotspot.
Because of the explanation in the very next paragraph.

An additional instance is created (two, if you count the closure that is hidden behind the innocent-looking "frames::add") and the add method is called for every StackFrameInfo. If the stack is deeper than 10, ArrayList will recreate the array used to store the entries followed by an Arrays.copyOf call.

There are different cases requiring different things. One of them is walking the entire stack trace and there are cases were starting at the front or the back might be beneficial. Other cases involve retrieving of a specific element at a known index. If I'm only interested in one StackTraceFrame it would definitely be overkill to retrieve the whole array. If I need the whole stack trace, though, it would be a bad idea to retrieve the stack trace step by step since that would mean multiple JNI calls. I think Nicks implementation took both cases into account.



Joern