Thanks!

Sent from my iPhone

> On 2016/05/13, at 7:21, Paul Benedict <[email protected]> wrote:
> 
> Here's a link to May's discussions in threaded format:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/thread.html#start
> 
> The discussion is under subject:
> "Review request 8153912: StackFrame::getFileName and 
> StackFrame::getLineNumber not needed"
> 
> But here's a shortcut:
> The discussion starts with this message. Click through using "Next message" 
> link in the message:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040826.html
> 
> Cheers,
> Paul
> 
>> On Thu, May 12, 2016 at 5:06 PM, Remko Popma <[email protected]> wrote:
>>  There seem to be a lot of openjdk mailing lists. I can't find it. Which one 
>> is this? (What was the Subject line of the discussion with Mandy Chung?)
>> 
>> 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