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 frameworks is that we really want access to the location information at compile time such that the overhead to include it would be zero. I’ve never understood why Java doesn’t include it. I wrote a Logging Framework for C back in the 1980’s that could include the Information so this isn’t a new concept. Even if I could do logger.debug(System.location(), ….) Where System.location is replaced by the compiler with a constant object would be a huge win. Ralph > On Apr 7, 2022, at 11:02 AM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > > Some loggers do need to find the location of the log statement (class and > line where the logger is used not where it is instantiated). > > for those (it makes loggers more useful) getting the call site is time > critical even if they are not in tight performance critical loops. > > But it actually does matter if/how the JVM optimizes such introspection.. if > the JVM can inline (and maybe even constant intrinsic) the stalkwalker it > would benefit such use cases just as well. > > -- > https://bernd.eckenfels.net > ________________________________ > From: core-libs-dev <core-libs-dev-r...@openjdk.java.net> on behalf of > Michael Kuhlmann <j...@fiolino.de> > Sent: Thursday, April 7, 2022 7:55:16 PM > To: core-libs-dev@openjdk.java.net <core-libs-dev@openjdk.java.net> > Subject: Re: fast way to infer caller > > > > On 4/7/22 19:27, Kasper Nielsen wrote: >>> >>> nope, see my previous mail to Ceki, the VM is cheating here if it can >>> inline the call to MethodHandles.lookup() >>> >> >> Does how the VM cheats really matter? The fact is that the code in the JDK >> can >> get the calling class and implement something like MethodHandles.lookup() so >> it takes ~3 ns. If you implemented something like a lookup class as a normal >> user your best bet would be StackWalker.GetCallingClass() and you would end >> up with something that is at least 2 magnitudes slower. That is probably not >> an issue for most use cases. But for some, it might be a bit of a steep >> cost. >> >> /Kasper > > Hi Kasper, > > sorry to jump in here as an uninvolved onlooker, but I can't resist. > I really don't see why this should matter. Getting the caller class is a > rare edge case that you just do in exceptional situations; most often > it's more for debugging or something. > > What users really are interested in is high performance for standard > cases. Implementing a specific optimization into Hotspot to gain few > milliseconds is the least thing I expect from the JVM developers. > > I also don't understand why someone should instantiate a logger during > performance critical procedures. In more than 20 years of Java > development, I've never seen the need to create a logger on the fly. > They are *always* assigned to final static variables, or at least to > predefined pools. Everything else would be just wrong: To instantiate a > logger, you have to fetch at least the log level definition from some > configuration source, and this can never be fast. At least not that > we're talking about nanoseconds here. > > All logging implementations I know of (and all that make sense) are > highly optimized on log throughput; this can only be achieved by > preprocessing during initialization, why this is slow. But that doesn't > matter, because, as said, you should anyway create logger instances > beforehand. > > Sorry for the rant, but I really don't see the use case here.
