RFR: 8295537: Debug tracing for resolved java.lang.invoke.CallSite [v2]

[Ioi Lam]

On Tue, 25 Oct 2022 18:54:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java line 329:
>> 
>>> 327:                 return null;
>>> 328:             }
>>> 329:         });
>> 
>> Not sure about this condition. It seems like `callerInfo[0] == callerName` will always be true at first, and then it gets overwritten by the stack trace element toString, so in effect it only picks up the first non-MethodHandleNatives caller? I think it could be clearer to use `filter` + `findFirst` to get the caller's `StackFrame` (that has the additional benefit of short-circuiting), and then convert to a String from there.
>> 
>> Also, please move the code that gets the caller info out-of-line to a helper method, since it's quite wordy.
>
> Alternatively, maybe you could just dump the whole stack trace here (e.g. with Thread.dumpStack()), since it might be useful to see which code path triggers resolution of a call site as well. That would also include the line number of the caller.

Is it possible to use filter/findfirst without using lambdas? I want to avoid recursion inside the tracing code.

I am not sure about dumping the call stack. It seems an overkill and not useful in most cases. It’s easier to rebuild the JDK and add Thread.dumpStack() in the rare occasion that you need to do this.

-------------

PR: https://git.openjdk.org/jdk/pull/10842