logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Williams <nicho...@nicholaswilliams.net>
Subject Re: Relfection.getCallerClass
Date Fri, 02 Aug 2013 23:34:29 GMT
I HATE their new numbering system. HATE.

ABHOR.

7u40 comes after 7u25. So, yes, it's the next one. Set to release mid-September.

Nick

On Aug 2, 2013, at 4:59 PM, Gary Gregory wrote:

> On Thu, Aug 1, 2013 at 10:01 PM, Nick Williams <nicholas@nicholaswilliams.net>
wrote:
> I can confirm that the JDK team /has/ committed the change to restore Reflection.getCallerClass()
in Java 7u40:
> 
> http://hg.openjdk.java.net/jdk7u/jdk7u40-dev/jdk/rev/244dbaeab45e
> 
> So, hurray! Lol.
> 
> With Oracle's new demented numbering scheme, how can you tell when this version is coming?
;) Is that the next Java 7 or the one after that?
> 
> Gary
> 
> Nick
> 
> On Aug 1, 2013, at 9:48 AM, Remko Popma wrote:
> 
>> O(n log n) would not be too bad, but what you're describing sounds more like quadratic
time!
>> That's huge, Nick, congrats! That would mean a big speed improvement for the location-based
layout patterns in Log4j, they use Thread.currentThread().getStackTrace() under the hood.
Nice!
>> 
>> -Remko
>> 
>> From: Nick Williams <nicholas@nicholaswilliams.net>
>> To: Log4J Developers List <log4j-dev@logging.apache.org> 
>> Sent: Thursday, August 1, 2013 10:11 PM
>> Subject: Re: Relfection.getCallerClass
>> 
>> Here's something interesting.
>> 
>> So the last method I had to write, StackTraceFrame.getStackTrace(Throwable), I finished
last night. It's the alternative to Throwable.getStackTrace(). Instead of returning StackTraceElement[]
(String for declaring class name), it returns StackTraceFrame[] (Class<?> for declaring
class). I expected this to perform about the same or possibly even worse--boy was I wrong.
>> 
>> StackTraceFrame.getStackTrace(Throwable) consistently returns in half the time that
Throwable.getStackTrace() does. Looking at why that is, I found a HUGE inefficiency in Throwable.getStackTrace().
StackTraceFrame.getStackTrace(Throwable) walks the backtrace 1 time and runs O(n), where n
is the number of elements in the stack trace. Throwable.getStackTrace() walks the back trace
1+(n/2) times (first it measures the depth of the back trace in one native method call, then
it gets the elements by index in a native method call for each, looping up to that index each
time), for an O(nlogn) (I think) running time. Much worse.
>> 
>> So ... I improved Throwable.getStackTrace() and cut its running time in half while
I was at it. This also resulted in cutting Thread.currentThread().getStackTrace()'s runtime
in half. Think they'll appreciate it? :-/
>> 
>> N
>> 
>> On Jul 31, 2013, at 4:42 PM, Paul Benedict wrote:
>> 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019486.html
>>> 
>>> 
>>> On Wed, Jul 31, 2013 at 4:40 PM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>> Hm... do you have a URL for this ray of hope?
>>> 
>>> Gary
>>> 
>>> 
>>> On Wed, Jul 31, 2013 at 5:34 PM, Paul Benedict <pbenedict@apache.org> wrote:
>>> Nevermind. I just found it. Lousy browser caching!
>>> 
>>> 
>>> On Wed, Jul 31, 2013 at 4:33 PM, Paul Benedict <pbenedict@apache.org> wrote:
>>> Did you find this out on the OpenJDK mailing list? I can't find the information;
I may have missed it.
>>> 
>>> 
>>> On Wed, Jul 31, 2013 at 4:22 PM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>> KA-POW! Well done, sir. How about we use your mug as the new logo? ;)
>>> 
>>> Gary
>>> 
>>> 
>>> On Wed, Jul 31, 2013 at 4:47 PM, Nick Williams <nicholas@nicholaswilliams.net>
wrote:
>>> A PARTIAL VICTORY!
>>> 
>>> They've decide to revert the change to Reflection.getCallerClass for 7u40 and
the rest of 7. Woohoo!
>>> 
>>> "What will happen to this method in JDK 8 requires further thought."
>>> 
>>> Meanwhile, about 300 lines of Java and 1,000 lines of native code later, I'm
about ready to submit my patch for a public API replacement in Java 8.
>>> 
>>> N
>>> 
>>> On Jul 29, 2013, at 8:39 AM, Gary Gregory wrote:
>>> 
>>>> What a mess :( it seem unlikely new APIs will be added to Java 8 to help
us, at least based on comments like http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019110.html
>>>> 
>>>> We might be left with documenting our side with "if you use features x and
y in this context then the speed will degrade to so and so, here is where to ask Oracle to
fix it: http:..."
>>>> 
>>>> Gary
>>>> 
>>>> On Jul 29, 2013, at 9:06, Nick Williams <nicholas@nicholaswilliams.net>
wrote:
>>>> 
>>>>> core-libs-dev
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>> 
>>> 
>>> 
>>> -- 
>>> Cheers,
>>> Paul
>>> 
>>> 
>>> 
>>> -- 
>>> Cheers,
>>> Paul
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>> 
>>> 
>>> 
>>> -- 
>>> Cheers,
>>> Paul
>> 
>> 
>> 
> 
> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


Mime
View raw message