Oh neat, I didn't know about that feature. On 11 May 2016 at 13:24, Paul Benedict <[email protected]> wrote:
> Matt, you can take advantage of the new Multi-Release Jar feature of JDK 9: > http://openjdk.java.net/jeps/238 > > This way you can provide a single artifact and have key classes replaced > for JDK 9 with your specialized implementation. > > > Cheers, > Paul > > On Wed, May 11, 2016 at 1:10 PM, Matt Sicker <[email protected]> wrote: > >> How would we do that while still making log4j compatible with 1.7 and 1.8? >> >> On 11 May 2016 at 12: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]> >>> >>> >>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >> > > -- Matt Sicker <[email protected]>
