Instrumenting call sites.

[MacGregor, Duncan (GE Energy Management)]

Yes, we are only likely to want instrumentation on rare occasions so I don't want to put that information into the BSM arguments, I'll go with using the debugging API.

Thanks, Duncan.

From: John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>>
Reply-To: Da Vinci Machine Project <mlvm-dev at openjdk.java.net<mailto:mlvm-dev at openjdk.java.net>>
Date: Friday, 30 November 2012 02:26
To: Da Vinci Machine Project <mlvm-dev at openjdk.java.net<mailto:mlvm-dev at openjdk.java.net>>
Subject: Re: Instrumenting call sites.

On Nov 29, 2012, at 11:15 AM, MacGregor, Duncan (GE Energy Management) wrote:

 1.  What is the recommended maximum tree size and longest path for composed MethodHandles (can we push our fast path limit a little higher)?

The JIT will inline through several layers of method handles.  We are tuning the meaning of "several", and are trying to be generous.  There's no a priori limit.

 2.  What's my best option for connecting call sites to specific points in byte code and hence to their source locations? Should I simply use JDI method entry events on the fallback methods and work my way up the stack past any java.lang.invoke infrastructure? Knowing where these sites are might help us refactor the code to avoid too many receivers being seen.

You could add the source location into the bootstrap method (BSM) arguments.

But if you only need it on rare occasions, you are probably better off using a debugging API to pull it out of the stack frames.

We (the EG) have toyed with the idea of somehow passing debug info into the BSM, but there does not seem to be a good way to do this that (a) does not put costs on clients that don't need the info and (b) is stable enough (in the presence of code transformers) to be meaningful to the BSM.  This problem is akin to the problem of annotating expressions and local variables; in particular, it is unsolved.

— John