ISSUE INSTRUCTION-PADDING

[John Rose]

 From the issue list:

> ISSUE INSTRUCTION-PADDING:  The invokedynamic instruction needs to  
> be 5 bytes long (for some JVM implementations, to allow embedded  
> coding of call site identity).  GIven that, shall the final two  
> bytes be (a) required to be zero and reserved for future use, or (b)  
> used for some present use?  (Default answer: (a).  No credible use  
> is known at present.)

While working on use cases, I realized there is a credibly generic use  
for those last two bytes in in the invokedynamic format:  They could  
link to the constant pool.  The constant (number, string, class,  
method handle, or method type) would be an (immutable) attribute of  
the call site, as CallSite.constant.

Advantages:
  - put in another parameter to CallSite that does not need to be  
interpretively constructed by the BSM
  - (unlike an uninterpreted string, this parameter, if a class or  
method, is subject to the linkage rules that govern constant pool  
references, which is a very good thing)
  - provide a hook for specifying, on a per-call basis, an initial or  
default call site target or call site factory (with any cooperating BSM)
  - allow construction of enriched calling sequences for method  
handles, without wiring them into MethodHandle.invoke itself (Fredrik  
& Neal's requests)
  - reduce (not eliminate) the need to put ad hoc encodings of JVM  
objects in the CallSite.name()
  - (with a structured constant mechanism also useful for initializing  
arrays, would *greatly* reduce those ad hoc encodings)
  - remove proposed impact on ldc instruction (see next)

In particular, they could link to Methodrefs and NameAndTypes in a way  
natural to invokedynamic, and as an alternative to extending the ldc  
instruction to provide "JVM-natural" access to constant method  
handles.  This could let us remove the following two issues:

> ISSUE METHOD-HANDLE-CONSTANTS: Shall we extend ldc to provide direct  
> access (via constant pools) to direct method handles via the  
> previously unused CONSTANT_Xref constant pool types, as an  
> alternative to the Lookup.find* methods (when the operands are  
> compile-time literals)?
>
> ISSUE METHOD-TYPE-CONSTANTS: Shall we extend ldc to provide direct  
> access (via constant pools) to method types via the previously  
> unused CONSTANT_Utf8 constant pool type, as an alternative to  
> MethodType.make (when the operands are compile-time literals)?

Disadvantages:
  - no credible Java language syntax for the extra information, unless  
we stuff it into the <...>; syntax for method refs is especially  
difficult given the current lack
  - JVM complexity (small, since the code that parses call sites is  
already very close to the constant pool and linkage machinery)

The use case of enriched MethodHandle.invoke was the consideration the  
brought me to this point.  Suppose you want to make a call site like  
MH.invoke, but with some set of automatic conversions.  You'll need to  
build the runtime infrastructure for this, of course (see the mlvm  
code for exactInvoker, genericInvoker, and varargsInvoker, for  
examples).  The infrastructure will be exposed as a public API,  
probably a method which is ready to perform the office of the  
bootstrap method; call it MySpecialCoercerLogic.bootstrap.  Then your  
enhanced method handle invoke would look something like this:
	Foo x =  
InvokeDynamic 
.<Foo>#"bootstrap:constant"(MySpecialCoercerLogic.#bootstrap(...);  
myMethodHandle, bar, baz, bat)

Actually, it can only be expressed in bytecodes, as noted above in the  
first disadvantage.  The string "bootstrap:constant" is arbitrary, and  
whatever BSM is local to the class would have to recognize that string  
and do the right delegation logic.

This doesn't feel fully cooked, but I thought I'd throw it out as a  
possibility.

Of course, one possibility would be to throw away the bootstrap  
registration machinery altogether, and just use the final two bytes as  
a direct pointer to the BSM.  That doesn't get the full range of use  
cases, though, since then those two bytes cannot be used to access  
another kind of constant (such as an initial target method).

-- John