[constant-folding] More indy experiments

[Tagir Valeev]

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[]).

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.

With best regards,
Tagir Valeev.

On Thu, May 11, 2017 at 4:47 PM, Maurizio Cimadamore <
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.
>
>
>