ISSUE INSTRUCTION-PADDING

[Rémi Forax]

John Rose a écrit :
>  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.
>   
Yes, these two empty bytes are very charming :)

> 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:
>   

Hugh !
I don't understand why it can remove the two new LDC.
The two empty bytes are only usable in case of an invokedynamic but
the two new LDC are also usefull in case of MethodHandle.invoke().

So in my opinion, using the two slots doesn't remove the issues about 
new LDC constants.

BTW, method handles are not shared, so an LDC that can produce
not constant value is stange.

LDC String.toString()
LDC String.toString()
IFEQ                              // true or false

>   
>> 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).
>   
Constants can be encoded in the BSM body even if it's not a verfy good 
design.
> -- John
>   
Rémi