* </li>

 * <li>In source code, the class {@link java.dyn.InvokeDynamic InvokeDynamic} appears to accept

 * </li>

 * the classes {@link java.dyn.MethodHandle MethodHandle} and {@link java.dyn.MethodType MethodType}.

 * </li>

 * The constant pool reference of an {@code invokedynamic} instruction is to a entry

 * with tag {@code CONSTANT_InvokeDynamic} (decimal 17).  See below for its format.

 * The entry specifies the bootstrap method (a {@link java.dyn.MethodHandle MethodHandle} constant),

 * the dynamic invocation name, and the argument types and return type of the call.

 * <p>

 * Each instance of an {@code invokedynamic} instruction is called a <em>dynamic call site</em>.

 * Multiple instances of an {@code invokedynamic} instruction can share a single

 * {@code CONSTANT_InvokeDynamic} entry.

 * In any case, distinct call sites always have distinct linkage state.

 * <p>

 * Moreover, for the purpose of distinguishing dynamic call sites,

 * the JVM is allowed (but not required) to make internal copies

 * of {@code invokedynamic} instructions, each one

 * constituting a separate dynamic call site with its own linkage state.

 * Such copying, if it occurs, cannot be observed except indirectly via

 * execution of bootstrap methods and target methods.

 * <p>

 * A dynamic call site is originally in an unlinked state.  In this state, there is

 * no target method for the call site to invoke.

 * A dynamic call site is linked by means of a bootstrap method,

 * as <a href="#bsm">described below</a>.

 * <p>

 * <em>(Historic Note: Some older JVMs may allow the index of a {@code CONSTANT_NameAndType}

 * instead of a {@code CONSTANT_InvokeDynamic}.  In earlier, obsolete versions of this API, the

 * bootstrap method was specified dynamically, in a per-class basis, during class initialization.)</em>

 *

 * <h3>constant pool entries for {@code invokedynamic} instructions</h3>

 * If a constant pool entry has the tag {@code CONSTANT_InvokeDynamic} (decimal 17),

 * it must contain exactly four more bytes.

 * The first two bytes after the tag must be an index to a {@code CONSTANT_MethodHandle}

 * entry, and the second two bytes must be an index to a {@code CONSTANT_NameAndType}.

 * The first index specifies a bootstrap method used by the associated dynamic call sites.

 * The second index specifies the method name, argument types, and return type of the dynamic call site.

 * The structure of such an entry is therefore analogous to a {@code CONSTANT_Methodref},

 * except that the {@code CONSTANT_Class} reference in a {@code CONSTANT_Methodref} entry

 * is replaced by a bootstrap method reference.

 * it must contain exactly two more bytes, which must be an index to a {@code CONSTANT_Utf8}

 * entry which represents a method type signature.

 * <p>

 * The JVM will ensure that on first

 * execution of an {@code ldc} instruction for this entry, a {@link java.dyn.MethodType MethodType}

 * value which must be in the range 1 through 9, and the last two must be an index to a

 * Furthermore, the subtag value and the type of the constant index value

 * must agree according to the table below.

 * <p>

 * for this entry, a {@link java.dyn.MethodHandle MethodHandle} will be created which represents

 * <h2><a name="bsm"></a>Bootstrap Methods</h2>

 * Before the JVM can execute a dynamic call site (an {@code invokedynamic} instruction),

 * the call site must first be <em>linked</em>.

 * Linking is accomplished by calling a <em>bootstrap method</em>

 * which is given the static information content of the call site,

 * and which must produce a {@link java.dyn.MethodHandle method handle}

 * that gives the behavior of the call site.

 * <p>

 * Each {@code invokedynamic} instruction statically specifies its own

 * bootstrap method as a constant pool reference.

 * The constant pool reference also specifies the call site's name and type signature,

 * just like {@code invokevirtual} and the other invoke instructions.

 * <p>

 * Linking starts with resolving the constant pool entry for the

 * bootstrap method, and resolving a {@link java.dyn.MethodType MethodType} object for

 * the type signature of the dynamic call site.

 * This resolution process may trigger class loading.

 * It may therefore throw an error if a class fails to load.

 * This error becomes the abnormal termination of the dynamic

 * call site execution.

 * Linkage does not trigger class initialization.

 * <p>

 * Next, the bootstrap method call is started, with four values being stacked:

 * <ul>

 * <li>a {@code MethodHandle}, the resolved bootstrap method itself </li>

 * <li>a {@code Class}, the <em>caller class</em> in which dynamic call site occurs </li>

 * <li>a {@code String}, the method name mentioned in the call site </li>

 * <li>a {@code MethodType}, the resolved type signature of the call </li>

 * </ul>

 * The method handle is then applied to the other values as if by

 * {@linkplain java.dyn.MethodHandle#invokeGeneric the <code>invokeGeneric</code> method}.

 * The returned result must be a {@link java.dyn.CallSite CallSite}, a {@link java.dyn.MethodHandle MethodHandle},

 * or another {@link java.dyn.MethodHandleProvider MethodHandleProvider} value.

 * The method {@linkplain java.dyn.MethodHandleProvider#asMethodHandle asMethodHandle}

 * is then called on the returned value.  The result of that second

 * call is the {@code MethodHandle} which becomes the

 * permanent binding for the dynamic call site.

 * That method handle's type must be exactly equal to the type

 * derived from the dynamic call site signature and passed to

 * the bootstrap method.

 * <p>

 * After resolution, the linkage process may fail in a variety of ways.

 * All failures are reported by an {@link java.dyn.InvokeDynamicBootstrapError InvokeDynamicBootstrapError},

 * which is thrown as the abnormal termination of the dynamic call

 * site execution.

 * The following circumstances will cause this:

 * <ul>

 * <li>the bootstrap method invocation completes abnormally </li>

 * <li>the result from the bootstrap invocation is not a reference to

 *     an object of type {@link java.dyn.MethodHandleProvider MethodHandleProvider} </li>

 * <li>the call to {@code asMethodHandle} completes abnormally </li>

 * <li>the call to {@code asMethodHandle} fails to return a reference to

 *     an object of type {@link java.dyn.MethodHandle MethodHandle} </li>

 * <li>the method handle produced by {@code asMethodHandle} does not have

 *     the expected {@code MethodType} </li>

 * </ul>

 * <h3>timing of linkage</h3>

 * A dynamic call site is linked just before its first execution.

 * The bootstrap method call implementing the linkage occurs within

 * a thread that is attempting a first execution.

 * <p>

 * If there are several such threads, the JVM picks one thread

 * and runs the bootstrap method while the others wait for the

 * invocation to terminate normally or abnormally.

 * <p>

 * After a bootstrap method is called and a method handle target

 * successfully extracted, the JVM attempts to link the instruction

 * being executed to the target method handle.

 * This may fail if there has been intervening linkage

 * or invalidation event for the same instruction.

 * If such a failure occurs, the dynamic call site must be

 * re-executed from the beginning, either re-linking it

 * (if it has been invalidated) or invoking the target

 * (if it the instruction has been linked by some other means).

 * <p>

 * If the instruction is linked successfully, the target method

 * handle is invoked to complete the instruction execution.

 * The state of linkage continues until the method containing the

 * dynamic call site is garbage collected, or the dynamic call site

 * is invalidated by an explicit request,

 * such as {@link java.dyn.Linkage#invalidateCallerClass Linkage.invalidateCallerClass}.

 * <p>

 * In an application which requires dynamic call sites with individually

 * mutable behaviors, their bootstrap methods should produce distinct

 * {@link java.dyn.CallSite CallSite} objects, one for each linkage request.

 * <p>

 * If a class containing {@code invokedynamic} instructions

 * is {@linkplain java.dyn.Linkage#invalidateCallerClass(Class) invalidated},

 * subsequent execution of those {@code invokedynamic} instructions

 * will require linking.

 * It is as if they had never been executed in the first place.

 * (However, invalidation does not cause constant pool entries to be

 * resolved a second time.)

 * <p>

 * Invalidation events and bootstrap method calls for a particular

 * dynamic call site are globally ordered relative to each other.

 * When an invokedynamic instruction is invalidated, if there is

 * simultaneously a bootstrap method invocation in process

 * (in the same thread or a different thread), the result

 * eventually returned must not be used to link the call site.

 * Put another way, when a call site is invalidated, its

 * subsequent linkage (if any) must be performed by a bootstrap method

 * call initiated after the invalidation occurred.

 * <p>

 * If several threads simultaneously execute a bootstrap method for a single dynamic

 * call site, the JVM must choose one target object and installs it visibly to

 * all threads.  Any other bootstrap method calls are allowed to complete, but their

 * results are ignored, and their dynamic call site invocations proceed with the originally

 * chosen target object.

 * <p>

 * The JVM is free to duplicate dynamic call sites.

 * This means that, even if a class contains just one {@code invokedynamic}

 * instruction, its bootstrap method may be executed several times,

 * once for each duplicate.  Thus, bootstrap method code should not

 * assume an exclusive one-to-one correspondence between particular occurrences

 * of {@code invokedynamic} bytecodes in class files and linkage events.

 * <p>

 * In principle, each individual execution of an {@code invokedynamic}

 * instruction could be deemed (by a conforming implementation) to be a separate

 * duplicate, requiring its own execution of the bootstrap method.

 * However, implementations are expected to perform code duplication

 * (if at all) in order to improve performance, not make it worse.

 *