316      * N+1: an implicitly added type argument (the given MethodType)

   319      * N+1: an optional, implicitly added argument (typically the given MethodType)

   320      * <p>

   321      * The nominal method at such a call site is an instance of

   322      * a signature-polymorphic method (see @PolymorphicSignature).

   323      * Such method instances are user-visible entities which are

   324      * "split" from the generic placeholder method in {@code MethodHandle}.

   325      * (Note that the placeholder method is not identical with any of

   326      * its instances.  If invoked reflectively, is guaranteed to throw an

   327      * {@code UnsupportedOperationException}.)

   328      * If the signature-polymorphic method instance is ever reified,

   329      * it appears as a "copy" of the original placeholder

   330      * (a native final member of {@code MethodHandle}) except

   331      * that its type descriptor has shape required by the instance,

   332      * and the method instance is <em>not</em> varargs.

   333      * The method instance is also marked synthetic, since the

   334      * method (by definition) does not appear in Java source code.

   335      * <p>

   336      * The JVM is allowed to reify this method as instance metadata.

   337      * For example, {@code invokeBasic} is always reified.

   338      * But the JVM may instead call {@code linkMethod}.

   339      * If the result is an * ordered pair of a {@code (method, appendix)},

   340      * the method gets all the arguments (0..N inclusive)

   341      * plus the appendix (N+1), and uses the appendix to complete the call.

   342      * In this way, one reusable method (called a "linker method")

   343      * can perform the function of any number of polymorphic instance

   344      * methods.

   345      * <p>

   346      * Linker methods are allowed to be weakly typed, with any or

   347      * all references rewritten to {@code Object} and any primitives

   348      * (except {@code long}/{@code float}/{@code double})

   349      * rewritten to {@code int}.

   350      * A linker method is trusted to return a strongly typed result,

   351      * according to the specific method type descriptor of the

   352      * signature-polymorphic instance it is emulating.

   353      * This can involve (as necessary) a dynamic check using

   354      * data extracted from the appendix argument.

   355      * <p>

   356      * The JVM does not inspect the appendix, other than to pass

   357      * it verbatim to the linker method at every call.

   358      * This means that the JDK runtime has wide latitude

   359      * for choosing the shape of each linker method and its

   360      * corresponding appendix.

   361      * Linker methods should be generated from {@code LambdaForm}s

   362      * so that they do not become visible on stack traces.

   363      * <p>

   364      * The {@code linkMethod} call is free to omit the appendix

   365      * (returning null) and instead emulate the required function

   366      * completely in the linker method.

   367      * As a corner case, if N==255, no appendix is possible.

   368      * In this case, the method returned must be custom-generated to

   369      * to perform any needed type checking.

   370      * <p>

   371      * If the JVM does not reify a method at a call site, but instead

   372      * calls {@code linkMethod}, the corresponding call represented

   373      * in the bytecodes may mention a valid method which is not

   374      * representable with a {@code MemberName}.

   375      * Therefore, use cases for {@code linkMethod} tend to correspond to

   376      * special cases in reflective code such as {@code findVirtual}

   377      * or {@code revealDirect}.