Re: fast way to infer caller

I mentioned this same concern back in 2017 when the Sun Reflection class was removed. In Log4j’s case there are two places that accessing the stack comes into play: 1. Obtaining a Logger . 2. Logging an event and including the caller’s location information. To be honest, what sucks for Logging

Re: Adding an @Immutable annotation to Java

I would think that if a class is marked immutable that would imply all the fields in it and from its inherited classes should be immutable. If fields are marked immutable then it would only apply to them. What I wonder is what its relationship to final would be. The final annotation implies

Re: RFR: 8266846: Add java.time.InstantSource

On Mon, 17 May 2021 07:50:22 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > It would good to get confirmation in the review from @dholmes-ora or Mark > Kralj-Taylor that my changes to the precise system clock are correct. > Specifically, I moved the code from

Re: RFR: 8266846: Add java.time.InstantSource

On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource Can you possibly find a way that this can be used in a garbage free manner? Providing a MutableInstant interface that allows the Instant object to be provided and have its values set by a

Re: Garbage Free Check

ould likely not be exactly synchronized with the values from > Instant. > > Regards, Roger > > > On 4/5/21 3:56 PM, Brian Goetz wrote: >> Project Valhalla will allow Instant to be migrated to a primitive class, >> which would address your problem. >> &g

Re: Garbage Free Check

:33 PM, Ralph Goers wrote: > > Interesting. I ran the test with > > openjdk version "16" 2021-03-16 > OpenJDK Runtime Environment (build 16+36-2231) > OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing) > > and it passed. I then ran it with >

Re: Garbage Free Check

quot; 2021-01-19 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.10+8-LTS-162) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) and it failed with all of them. Ralph > On Apr 6, 2021, at 3:22 PM, Ralph Goers wrote: > > I am using > > ope

Re: Garbage Free Check

Error Units > InstantBench.epochMilli avgt 10 33.612 ± 0.258 > ns/op > InstantBench.epochMilli:·gc.alloc.rate avgt 10 ≈ 10⁻⁴ > MB/sec > InstantBench.epochMilli:·gc.alloc.rate.norm avgt 10 ≈ 10⁻⁵ > B/o

Re: Garbage Free Check

ystem.nanoTime(). > Though it would likely not be exactly synchronized with the values from > Instant. > > Regards, Roger > > > On 4/5/21 3:56 PM, Brian Goetz wrote: >> Project Valhalla will allow Instant to be migrated to a primitive class, >> which would address yo

Re: Garbage Free Clock

Does anyone have any thoughts or suggestions on this please? Ralph > On Apr 2, 2021, at 4:47 PM, Ralph Goers wrote: > > Log4j 2 supports the notion of a PreciseClock - one that can be initialized > to something more precise than a millisecond. At the same time it also > s

Garbage Free Check

Log4j 2 supports the notion of a PreciseClock - one that can be initialized to something more precise than a millisecond. At the same time it also supports running with no heap allocations in certain circumstances. I am in the process of moving our master branch to require Java 11 as the

Re: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass()

k.java.net/browse/JDK-8189752 > <https://bugs.openjdk.java.net/browse/JDK-8189752> to take a snapshot of a > stack trace (possibly the top N frames). > > Mandy > > On 7/2/19 2:49 PM, Ralph Goers wrote: >> The timing of this question is perfect. I have been doing some testing ov

Re: Slow performance of StackWalker.getCallerClass() vs Reflection.getCallerClass()

The timing of this question is perfect. I have been doing some testing over the last week to address https://issues.apache.org/jira/browse/LOG4J2-2644 and found some interesting things - although they are related to the walk() method, not

Re: revisiting MDC in slf4j broken because of CompletableFuture

gt; > There are weird methods and I would just not worry about those except as it > relates mostly to getting slf4j's MDC to work. > > On Thu, Mar 22, 2018 at 12:27 PM, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > My point

Re: revisiting MDC in slf4j broken because of CompletableFuture

do apologize if you do not read scala code, but the answer is there and > just in a different language) > > later, > Dean > > > On Thu, Mar 22, 2018 at 11:40 AM, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > H

Re: revisiting MDC in slf4j broken because of CompletableFuture

a ThreadLocal from one thread to a worker thread. I am guessing that is what you are really asking for is some sort of property on the Executor that tells it to pass the ThreadLocals from one thread to the worker that performs action on its behalf. Ralph > On Mar 22, 2018, at 10:13 AM, Ra

Re: revisiting MDC in slf4j broken because of CompletableFuture

Log4j 2 supports a ThreadContext which is analogous to the SLF4J MDC. Both are based on ThreadLocal variables. If I understand what you are saying, the problem is that ThreadLocals do not work as you you would expect when using CompleteableFutures? Ralph > On Mar 22, 2018, at 7:05 AM, Dean

Re: Android and Log4j

c 6, 2017, at 10:25 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Martin, > > Do they also ignore the class files in META-INF/versions? > > Ralph > >> On Dec 6, 2017, at 2:35 PM, Martin Buchholz <marti...@google.com> wrote: >> >> Ve

Re: Android and Log4j

Martin, Do they also ignore the class files in META-INF/versions? Ralph > On Dec 6, 2017, at 2:35 PM, Martin Buchholz wrote: > > Very latest Android Studio comes with two compilers, dx and d8. > https://developer.android.com/studio/preview/features/index.html >

Re: Android and Log4j

> On Dec 3, 2017, at 12:19 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 03/12/2017 18:25, Ralph Goers wrote: >> Log4j added support for Java 9 by: >> Converting the Log4j-API jar to a multi-release jar that includes support >> for StackWalk

Android and Log4j

Log4j added support for Java 9 by: Converting the Log4j-API jar to a multi-release jar that includes support for StackWalker and the new Process Id support. Adding a module-info.jar to the Log4j API jar. We are now getting complaints from Android users (as well as a few others) that their tools

Re: Change in properties for logging: deliberate?

Can’t you just deprecate java.util.logging? While I am half kidding, can someone explain why it doesn’t use a ServiceLoader to locate the LogManager implementation? Ralph > On Nov 10, 2017, at 9:04 AM, Daniel Fuchs wrote: > > Hi Jason, > > I have done a few tests

Re: Decreased latency performance with Stack Walker API compared to sun.misc.JavaLangAccess

This would could also make sense for asynchronous logging with Log4j 2. We currently disabled capturing location information for asynchronous logging as capturing the information before passing the information to the thread doing the logging is fairly expensive. Being able to capture the stack

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

enjdk.java.net/browse/JDK-8176593 > <https://bugs.openjdk.java.net/browse/JDK-8176593> for > Throwable::getStackTrace performance regression. > >> On Mar 13, 2017, at 1:57 PM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: >> >> Hi Ralph, >> >>

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

r way to bail out of the loop after I have found the correct StackFrame that would help as well. Ralph > > On 13/03/2017 18:52, Ralph Goers wrote: >> The “search” that uses StackWalker probably walks it to the end because >> I had to use test() to determine the StackFrame to re

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On Mar 13, 2017, at 11:54 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > >> On Mar 13, 2017, at 11:52 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >>> >>> On Mar 13, 2017, at 11:32 AM, Daniel Fuchs <daniel.fu...@oracle

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On Mar 13, 2017, at 11:52 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> >> On Mar 13, 2017, at 11:32 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: >> >> Hi Ralph, >> >> On 13/03/2017 04:25, Ralph Goers wrote: >>>

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On Mar 13, 2017, at 11:32 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Ralph, > > On 13/03/2017 04:25, Ralph Goers wrote: >> Sorry for not getting back sooner but I finally found some time to follow up. >> >> I took a look at >> htt

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

due to the walking of the stack itself, at > least based on what I measured. > > HTH, > -Brent > > On 5/10/16 9:49 AM, Ralph Goers wrote: >> I just ran one of the Log4j performance tests that specifically captures >> location information. To run the test I do >&g

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

users do with Log4j wouldn’t be possible or at least would be hard to debug. I have to believe that jul will have the same problem with custom handlers written by users. Ralph > On May 11, 2016, at 10:20 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi, > > On

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

OK, I will try to give that a try over the next few days and try to see how much overhead it incurs. Ralph > On May 11, 2016, at 9:43 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On May 11, 2016, at 9:24 AM, Ralph Goers <ralph.go...@dslextreme.com&

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

9:35 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Ralph, > > On 11/05/16 18:14, Ralph Goers wrote: >> You are correct that most of the time it would be faster to start from frame >> 0. However, the problem we have with walking the stack from frame 0 is tha

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

it. In looking at getCallerClass it isn’t clear to me how fast it actually is. Ralph > On May 11, 2016, at 9:14 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Yes, we need the StakWalker API for other parts of our code where we need the > Class so we can determine what

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

016, at 7:22 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Ralph, > > On 10/05/16 19:40, Ralph Goers wrote: >> The benchmark logs events using Log4j 2’s asynchronous loggers. In the >> process of doing that it captures the location information using the

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On May 10, 2016, at 7:34 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Here is the link to the source - > https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-perf/src/main/java/org/apache/logging/log4j/perf/jmh/AsyncAppenderLog4j2Locati

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

j2.git Ralph > On May 10, 2016, at 7:26 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On May 10, 2016, at 5:17 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> OK - I try that. My earlier comparison had shown that StackWalker was much &g

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> >> On May 10, 2016, at 10:40 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> The benchmark logs events using Log4j 2’s asynchronous loggers. In the >> process of doing that it captures the location information using the code >> below:

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

May 10, 2016, at 9:57 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > What does your benchmark call? > > Mandy > >> On May 10, 2016, at 9:49 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> I just ran one of the Log4j performance tests

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

getStackTraceElements method. > > Mandy > >> On Apr 13, 2016, at 11:49 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> I did a raw test of StackWalker by itself and the performance was much >> better than using a Throwable to get the location inf

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

on of > JDK-8153123 was to simplify the hotspot implementation that the runtime team > had concern about. There is an open issue to follow up the performance > (JDK-8153683). It’d be helpful to get your feedback on using StackWalker API > and the performance data. > > Mandy &g

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

I had planned on using StackWalker to generate the location information for every logging event. It seems that this change would thus cause the creation of a new StackTraceElement for every logger event. That seems wasteful. Log4j is currently in the process of trying to reduce the number of

Re: JEP 264: Platform Logging API and Service

t 9:50 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Ralph, > > On 30/09/15 18:30, Ralph Goers wrote: >> What would be preferable is to have the serviceLoader accept “criteria” >> (which are callbacks) that can evaluate each of the located services based

Re: JEP 264: Platform Logging API and Service

Bateman <alan.bate...@oracle.com> wrote: > > On 30/09/2015 14:59, Ralph Goers wrote: >> If I understand you correctly, then no that isn’t what I would want. The >> version and priority are captured in the same properties file where the >> class name is specified. If

Re: JEP 264: Platform Logging API and Service

FWIW, I considered using the ServiceLoader to bind the Log4j API to the implementation. However, Log4j also includes the API version and only looks for bindings that implement that version. We also include a “priority” - the binding with the highest priority wins - at the moment. At some future

Re: JEP 264: Platform Logging API and Service

I do have some questions on this. Would anyone realistically be able to use SLF4J/Logback or Log4j 2 as the implementation? The logging implementation needs to be able to configure itself before logging can realistically be performed. If logging initialization happens too soon the

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

On Sep 18, 2013, at 9:30 AM, Nick Williams wrote: On Sep 3, 2013, at 7:02 PM, Mandy Chung wrote: So for log4j to work with security manager installed, it would have torequire the application to grant certain permissions - can you confirm? Maybe one of the other Log4j guys listening

Re: Replacement of sun.reflect.Reflection#getCallerClass

I'd just like to add to this thread that Log4j is copying behavior that has been in Logback for years. The default behavior for both is to print a stack trace that includes the jar or directory where the class was located and its version. User's find this extremely helpful when diagnosing

Re: Replacement of sun.reflect.Reflection#getCallerClass

In Log4j's case the information we want from each StackTraceFrame is: a) the class name, b) the jar or directory where the class resided. c) the version of the jar. d) the ClassLoader associated with the class. Having the actually Class object allows us to get all of this information but if it

Re: Replacement of sun.reflect.Reflection#getCallerClass

I just subscribed so I apologize that this message is probably not going to be threaded properly. It seems mailman has no way for me to retrieve a message. I'd like to add a couple points to what you have below: 1. In addition to Log4j, Logback has been adding this same information to the