The JVM wants a pointer to a MethodType. Oblige it by finding or creating one.

Use best possible cause for err.initCause(), substituting the cause for err itself if the cause has the same (or better) type.

Is this method a caller-sensitive method? I.e., does it call Reflection.getCallerClass or a similar method to ask about the identity of its caller?

A BSM runs in pull-mode if and only if its sole arguments are (Lookup, BootstrapCallInfo), or can be converted pairwise to those types, and it is not of variable arity. Excluding error cases, we can just test that the arity is a constant 2.

The JVM is linking an invokedynamic instruction. Create a reified call site for it.

The JVM wants to link a call site that requires a dynamic type check. Name is a type-checking invoker, invokeExact or invoke. Return a JVM method (MemberName) to handle the invoking. The method assumes the following arguments on the stack: 0: the method handle being invoked 1-N: the arguments to the method handle invocation N+1: an optional, implicitly added argument (typically the given MethodType)

The nominal method at such a call site is an instance of a signature-polymorphic method (see @PolymorphicSignature). Such method instances are user-visible entities which are "split" from the generic placeholder method in MethodHandle. (Note that the placeholder method is not identical with any of its instances. If invoked reflectively, is guaranteed to throw an UnsupportedOperationException.) If the signature-polymorphic method instance is ever reified, it appears as a "copy" of the original placeholder (a native final member of MethodHandle) except that its type descriptor has shape required by the instance, and the method instance is not varargs. The method instance is also marked synthetic, since the method (by definition) does not appear in Java source code.

The JVM is allowed to reify this method as instance metadata. For example, invokeBasic is always reified. But the JVM may instead call linkMethod. If the result is an * ordered pair of a (method, appendix), the method gets all the arguments (0..N inclusive) plus the appendix (N+1), and uses the appendix to complete the call. In this way, one reusable method (called a "linker method") can perform the function of any number of polymorphic instance methods.

Linker methods are allowed to be weakly typed, with any or all references rewritten to Object and any primitives (except long/float/double) rewritten to int. A linker method is trusted to return a strongly typed result, according to the specific method type descriptor of the signature-polymorphic instance it is emulating. This can involve (as necessary) a dynamic check using data extracted from the appendix argument.

The JVM does not inspect the appendix, other than to pass it verbatim to the linker method at every call. This means that the JDK runtime has wide latitude for choosing the shape of each linker method and its corresponding appendix. Linker methods should be generated from LambdaForms so that they do not become visible on stack traces.

The linkMethod call is free to omit the appendix (returning null) and instead emulate the required function completely in the linker method. As a corner case, if N==255, no appendix is possible. In this case, the method returned must be custom-generated to perform any needed type checking.

If the JVM does not reify a method at a call site, but instead calls linkMethod, the corresponding call represented in the bytecodes may mention a valid method which is not representable with a MemberName. Therefore, use cases for linkMethod tend to correspond to special cases in reflective code such as findVirtual or revealDirect.

The JVM is resolving a CONSTANT_MethodHandle CP entry. And it wants our help. It will make an up-call to this method. (Do not change the name or signature.) The type argument is a Class for field requests and a MethodType for non-fields.

Recent versions of the JVM may also pass a resolved MemberName for the type. In that case, the name is ignored and may be null.

Map a reflective exception to a linkage error.

Tell the JVM that we need to change the target of a CallSite.

The JVM is requesting pull-mode bootstrap when it provides a tuple of the form int[]{ argc, vmindex }. The BSM is expected to call back to the JVM using the caller class and vmindex to resolve the static arguments.