[constant-folding] More indy experiments

[Maurizio Cimadamore]

On 11/05/17 11:19, Tagir Valeev wrote:
> Having current invokedynamic signature spec change will be necessary 
> anyways.
> I don't see publicly available spec draft for Java 9, but for Java 8 
> it requires that
> polymorphic signature method "takes a single variable arity parameter 
> (§8.4.1)
> whose declared type is Object[]." (§15.12.3). Currently it takes three 
> arguments
> (of which the last one is variable-arity Object[]).
This is all true, but I see the changes required here more in the spirit 
of what's been done for VarHandles - that is, allow some non-polymorphic 
parts in an otherwise polymorphic signature. That is:

1) polysig methods started off with polymorphic Object return type, and 
polymorphic argument list Object...

2) with VarHandles, the return type can now be non-polymorphic (e.g. 
boolean, or void)

3) with folding, I believe we are moving in a direction where we'd like 
to prepend some non-polymorphic arguments before the polymorphic varargs

All these changes are relatively straightforward and non controversial 
extensions of the polymorphic signature machinery. Adding inference 
support so that the return type can be inferred by javac is on another 
scale, and, as mentioned in the previous email, it's the technical 
aspect of it is not the most worrying thing (we know how to do method 
type inference :-)), but it smells like something that was already 
considered - and rejected - as part of 292, and something that moves 
things more towards a 'less explicit' direction.

So, while I agree it would be desirable to enhance the polysig machinery 
to remove unnecessary restrictions (allow generic methods, allow 
instantiation of generic instance type parameters, etc.), I'd say that 
it would be best to treat these as orthogonal improvements that can 
benefit all polysig players, rather than making this a 'requirement' for 
the current constant folding effort.

>
> Btw folding BootstrapSpecifier and name into single object and making 
> invokedynamic
> an instance method of that object (making it actually single variable 
> arity parameter method)
> would not require less spec changes regarding polymorphic signatures. 
> This would also
> simplify user code in my sample. The drawback is that bytecode 
> intrinsics will not be declared
> in the same class anymore. Though probably it's not very big problem, 
> given the fact that there
> are only two intrinsics.
Static vs. instance is a dimension in the design space - it is not only 
valid for indy, but I think, more broadly, for ldc too (which could be 
an instance method of Constable). Since these methods are very 'magic', 
I kind of like that they are currently defined in a separate class, 
where javadoc can explicitly call out the odd nature of those methods. 
If the methods are instance methods interleaved with other 'normal' 
methods in the Constable API, I think it would be slightly murkier - but 
in any case worth considering.

Cheers
Maurizio
>
> With best regards,
> Tagir Valeev.
>
> On Thu, May 11, 2017 at 4:47 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>
>     On 11/05/17 05:41, Tagir Valeev wrote:
>>     Hello, Maurizio!
>>
>>     Thank you for your answers!
>>
>>         As for (2) - the extra boxing you are observing is caused by
>>         the fact that Intrinsic.invokedynamic is not (yet) a
>>         polymorphic signature method (note that the polysig
>>         annotation is mentioned in the JEP). When it will be, boxing
>>         will disappear. But I think that if we go down the polysig
>>         path, then an explicit cast for the return type would be
>>         necessary (as it is for i.e. MethodHandle.invokeExact).
>>
>>
>>     I'm not aware about concrete implementation details in javac, but
>>     from an outsider point of view it should be doable. For normal
>>     generic return value javac is capable to automatically insert
>>     proper checkcast bytecode after call. The same type exactly
>>     should be used as MethodType return type for polysig
>>     invokedynamic if explicit cast is absent.
>     Doable yes - but note that it would require a spec change - as per
>     JDK 8, the declaration of a polysignature method is only allowed
>     to return Object. If there's no cast, Object is the return type
>     you get (unless you are in a statement expression, in which case
>     you get void), so to get any other return type you need to insert
>     a cast expression, which will be interpreted by javac as a signal
>     that you want to change the return type of the underlying
>     MethodType CP entry associated with the polysig call. This is the
>     status quo; I believe the idea of using return type inference
>     floated around at the time JDK 7 was developed, and I think that
>     one of the concerns in making return type inference more magic was
>     that if the return type is inferred as in a generic method call,
>     then there's a chance that your underlying signature might not be
>     stable in the face of subtle changes to the inference algorithm.
>
>     Note also that JEP 193 (VarHandles) [1] updated the rules for
>     polymorphic signature methods, allowing non-polymorphic return
>     types into the mix, which might also play a factor here.
>
>     Maurizio
>>
>>     With best regards,
>>     Tagir Valeev.
>
>