> On Apr 6, 2022, at 3:54 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> ----- Original Message -----
>> From: "Ceki Gülcü" <c...@qos.ch>
>> To: "core-libs-dev" <core-libs-dev@openjdk.java.net>
>> Sent: Wednesday, April 6, 2022 11:26:39 PM
>> Subject: Re: fast way to infer caller
>
>> Hi Rémi,
>>
>
> Now, i don't think there is a real solution to you issue, worst i will try to
> convince you that this is not a real problem :)
> You are offering convenience using magic to your user, this has a cost.
>
> For me this is very similar to the trade off you have by offering to change
> the logger configuration at runtime.
> This is convenient but it requires a volatile read (even when the logger is
> de-activated) which destroy performance in tight loop (you loose hoisting).
> I believe that if your users are fine with that, they are also fine with a
> call to LoggerFactory.getLogger() being a little slow.
>
We're only one user, but we use Logback and always assumed getLogger was
reasonably expensive, and that the most effort went into optimizing the actual
logging itself.
So we always store it in a static (preferred) or at least instance field, and
if we ever dynamically look it up we assume that's more expensive.
To us, the convenience of calling getLogger() over getLogger(MyClass.class) is
a nice win, and even 10x the execution speed of calling getLogger doesn't
matter at all.
If the performance cost was documented we would still use it without hesitation.
Just my 2¢,
Steven
>
>
>>
>>
>> On 4/6/2022 5:52 PM, Remi Forax wrote:
>>> ----- Original Message -----
>>>> From: "Ceki Gülcü" <c...@qos.ch>
>>>> To: "core-libs-dev" <core-libs-dev@openjdk.java.net>
>>>> Sent: Wednesday, April 6, 2022 5:30:51 PM
>>>> Subject: fast way to infer caller
>>>
>>>> Hello,
>>>
>>> Hello,
>>>
>>>>
>>>> As you are probably aware, one of the important primitives used in
>>>> logging libraries is inferring the caller of a given logging statement.
>>>> The current common practice is to create a throwable and process its
>>>> stack trace. This is rather wasteful and rather slow. As an alternative,
>>>> I have tried using the StackWalker API to infer the caller but was
>>>> unsatisfied with the performance.
>>>>
>>>> MethodHandles.lookup().lookupClass() looks very promising except that
>>>> there is no way to specify the depth.
>>>>
>>>> I am looking for a method to obtain the Nth caller at a cost of around
>>>> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
>>>> for this use case?
>>>
>>> We have designed the StackWalker with that in mind
>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html
>>>
>>> see the discussion on StackWalker.getCallerClass()
>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass()
