File name, method name, and line number constants

[Ralph Goers]

Yes, I understand this list is for the development of the javac compiler but since what I am asking for would be implemented by the javac compiler it seemed like the right place to start. I am sure that the information I am asking for is not the only information that would be good to have. I’ve often wondered why it doesn’t as it surely must have been considered at some point. 

Although I haven’t looked at using an agent, Log4j already has an annotation processor which I have thought about updating for this. But when I looked at that I didn’t see how it could get any of the information either.

Ralph


> On Apr 11, 2022, at 8:27 PM, Jesper Steen Møller <jesper at selskabet.org> wrote:
> 
> Hi Ralph,
> 
> If I understand correctly, you’re requesting a mechanism for a kind of compiler-“intrinsic” feature. However, such an optimization can fairly easily be provided today, e.g. using an agent where the calling bytecode is rewritten, perhaps in concert with the dynamic constant features of the JVM.
> 
> Adding runtime or language features is expensive in terms of future maintenance - reusing existing facilities is IMHO the preferable approach to solving this kind of problem. There are intrinsics in the JVM (and even in the language) for stuff like MethodHandle, but new features should be saved for the situations where there are no workarounds available and such features would unlock novel uses or long-standing pains of the platform. Project Panama is one such example, I suppose, where a similar agent-based approach wouldn’t cut it, and real JVM-level untrinsics are used instead.
> 
> By the way, this list is dedicated to development of the “javac”-compiler, and not to Java language suggestions as such.
> 
> -Jesper
> 
>> On 11 Apr 2022, at 10.44, Ralph Goers <rgoers at apache.org> wrote:
>> 
>> Logging frameworks such as Log4j 2 provide the ability to include the caller’s line number, method name, class name, file name, and possibly module name in every log event. Currently, collecting this data requires a call to StackWalker for every event logged. This is very expensive. Since this information could be determined at compile time it seems logical that the compiler could inject it where requested. For example, a logging call like:
>> 
>> logger.debug(System.currentStackTraceElement(), “log message”);
>> 
>> Could have the call to currentStackTraceElement() replaced by the compiler with a constant StackTraceElement containing the correct information. This would result in zero overhead at runtime instead of expensive call we have to perform now. It would have the drawback that uses would have to add that to the method invocation but that is a small price to pay for the efficiency gain.
>> 
>> Cound this, or something like it, be added?
>> 
>> Ralph