It would be different. We would be getting the location info in AbstractLogger 
in every API method. You wouldn't be able to delay it until it is 
requested/required.

Ralph

> On May 11, 2016, at 3:21 PM, Remko Popma <[email protected]> wrote:
> 
> The current way to get location information is not garbage-free either, so 
> this is not a problem. 
> 
> Have you tried benchmarking this? I'm very curious!
> 
> Sent from my iPhone
> 
>> On 2016/05/12, at 2:06, Ralph Goers <[email protected]> wrote:
>> 
>> For those you not following the OpenJDK mailing list, Mandy is recommending 
>> we do
>> 
>> walker.walk(s -> s.skip(2).findFirst());
>> 
>> in every logger method to capture the stack frame information. We might have 
>> to call it twice to get the Class as well. This will probably break the 
>> garbage free tests and it might incur more overhead then is acceptable. We 
>> will have to do some testing to find out.
>> 
>> Ralph
>> 
>> 
>> 
>>> On May 10, 2016, at 10:41 AM, Ralph Goers <[email protected]> 
>>> wrote:
>>> 
>>> We don’t use that for getting the caller location. We only use the 
>>> throwable. You are thinking of the code that needs to get the caller’s 
>>> Class object.
>>> 
>>> Ralph
>>> 
>>>> On May 10, 2016, at 10:33 AM, Matt Sicker <[email protected]> wrote:
>>>> 
>>>> JDK 9 should be blocking the sun.reflect classes which means we fall back 
>>>> to SecurityManager or Throwable depending on the method.
>>>> 
>>>> On 10 May 2016 at 11:51, Ralph Goers <[email protected]> wrote:
>>>>> I just responded to that thread with the results below.  I was hoping we 
>>>>> wouldn’t need to use the StackWalker API.  Now I am wondering if it is 
>>>>> any faster. My initial tests showed it was much faster than using the 
>>>>> Throwable, but that doesn’t mean much if that is now slower.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>> On May 10, 2016, at 9:47 AM, Ralph Goers <[email protected]> 
>>>>>> wrote:
>>>>>> 
>>>>>> No. On the openjdk list Mandy said that walking the Throwable as we are 
>>>>>> doing should be faster due to improvements made in JDK-8150778.
>>>>>> 
>>>>>> Ralph
>>>>>> 
>>>>>>> On May 10, 2016, at 9:21 AM, Paul Benedict <[email protected]> wrote:
>>>>>>> 
>>>>>>> Are you using the new JDK 9 APIs to walk the stack?
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Paul
>>>>>>> 
>>>>>>>> On Tue, May 10, 2016 at 11:20 AM, Ralph Goers 
>>>>>>>> <[email protected]> wrote:
>>>>>>>> Supposedly Java 9 was supposed to improve the performance of walking 
>>>>>>>> the stack trace. However, the numbers I get below indicate to me that 
>>>>>>>> they are moving in the opposite direction.  Am I misreading this?
>>>>>>>> 
>>>>>>>> Ralph
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> java version "1.7.0_80
>>>>>>>> 
>>>>>>>> Benchmark                                                             
>>>>>>>> Mode  Samples       Score      Error  Units
>>>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple    
>>>>>>>> thrpt       20  124819.285 ± 3003.918  ops/s
>>>>>>>> 
>>>>>>>> java version "1.8.0_65"
>>>>>>>> 
>>>>>>>> Benchmark                                                             
>>>>>>>> Mode  Samples       Score      Error  Units
>>>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple    
>>>>>>>> thrpt       20  123209.746 ± 3064.672  ops/s
>>>>>>>> 
>>>>>>>> 
>>>>>>>> java version "9-ea"
>>>>>>>> Java(TM) SE Runtime Environment (build 9-ea+116)
>>>>>>>> 
>>>>>>>> Benchmark                                                             
>>>>>>>> Mode  Samples      Score      Error  Units
>>>>>>>> o.a.l.l.p.j.AsyncAppenderLog4j2LocationBenchmark.throughputSimple    
>>>>>>>> thrpt       20  96090.261 ± 4565.763  ops/s
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Matt Sicker <[email protected]>
>>> 
>> 

Reply via email to