New JEP: Javac intrinsics for LDC and INVOKEDYNAMIC

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: valhalla-dev at openjdk.java.net
> Envoyé: Mardi 11 Avril 2017 18:50:56
> Objet: Re: New JEP: Javac intrinsics for LDC and INVOKEDYNAMIC

>> I like this JEP :)
> 
> I thought you might :)
> 
> It took us a long time to find a way of surfacing this feature that we
> like.  This is at least our fourth design iteration over several years;
> the others weren't worth sharing :)
> 
>> ldc:
>>    i don't like having to use another constant hierarchy,
>>    i would prefer to have static factories
> 
> Let's save the API design discussion for later -- right now, review
> comments should focus on the scope of the JEP.  But as a general goal,
> we're trying to keep the surface area of the intrinsified portion small
> -- right now, it's two methods (ldc and indy). Remember, this is an
> advanced tool for low-level programming; convenience methods may not be
> as needed as they might be with other APIs.

The compiler also have to know all implementations of Constable and all methods that override Constable.resolveConstant, so your API have more entry points.
What i propose decouple how the user specify a constant from how its represented in the constant pool.

The API i propose
- may not support the 'ConstantDynamic' depending on what exactly a ConstantDynamic is.
- do not support unknown constant pool constant but that's an explicit no goal.

The main difference is that you propose an API based on a tree of object while i think that a constant can be represented as a tree of method call.

> 
>>    by example for constMethodHandle, the compiler
>>    - requires all arguments to be constants
>>    - emits an error if the underlying method do not exist or the tag is not valid,
>>    etc at compile time,
>>    - replace the call with a ldc with the right constant pool constant if the
>>    constant is not constant-folded because it's part of another constant
> 
> The LDC intrinsification is the point at which we must enforce that we
> have a constant in hand.  The XxxConstant classes can freely tolerate
> non-constant content (perhaps they should be renamed), it's only when we
> want to intrinsify that a constant is truly needed.

yes, so you do not need XxxConstant per se but just a method that takes parameters and returns a constant pool constant, hence the API i propose.

The API you propose is more powerful because it allows to create objects that are considered as constant by the compiler but given that at the end you can only emit ldc of the existing constants.
If think that we can have a simpler API using method call instead of object from the user POV and you are free to inside the compiler uses an API like the one you propose to implement the simpler API.

> 
>>    - the BootstrapSpecifier should only contain a constant MethodHandle and an
>>    array of constant and a name, the descriptor should be computed by the compiler
>>    from the callsite, what @PolymorphicSignature already does.
> 
> That's a valid alternative (which we considered.)  Again, if the goal is
> to allow explicit control over indy, it seems preferable to put the
> MethodType in the indy descriptor -- as this more closely models the
> BootstrapMethods entry -- and have that take precedence -- and then we
> can type-check the call site (and adapt args/returns appropriately)
> against the "official" descriptor.

@PolymorphicSignature let you add casts to get the 'official' descriptor you want.
Here, you have a redundant info so the compiler
- can use the descriptor encoded in the bootstrap specifier to do inference (right ?)
- has to verify that the signature computed by the algo behind @PolymorphicSignature is a subsignature of the one of the bootstrap specifier.
So this is a new specific way to transfer signature info to the compiler, not @PolymorphicSignature per se.
I do not see the point to add another algorithm to do @PolymorphicSignature but not exactly in the compiler and the Java spec.

> 
>>    a counter-proposal, let say we have an empty class
>>      class InvokedynamicCompilerIntrinsics {
>>        // empty
>>      }
>>   
>>    introduce a new syntax,
> 
> I understand why you want this, but .... no :)
> 
> It is an explicit anti-goal to have language syntax for this feature.
> (Finding an acceptable way to do this is part of why we had to wait this
> long.)  This is a feature for a few hundred people, at most.  Adding
> language surface for this would merely encourage the book authors /
> training providers of the world to include it (either because it seems
> new and cool, or out of a desire to be comprehensive) -- thereby
> exposing the other 99.9999% of the Java ecosystem to a feature they will
> never -- and should never -- use. (Balancing the needs of advanced
> developers while not polluting "everyone's Java" is a very difficult
> balance.)

If it's only a few hundred, i know all of them :)
I teach the java.lang.invoke API since 2011 [1], so a few hundred at my uni have all used ASM to encode enough invokedynamics to implement a small dynamic language :)

And what about a Java compatible syntax that still separate the bootstrap arguments from the regular arguments ?

  class InvokedynamicCompilerIntrinsics {
        // empty
  }

  MethodHanlde bsm = ... // a constant method handle to a bootstrap method
  Xxx bsmargs = ... // some constants
  InvokedynamicCompilerIntrinsics.bsm(bsm, bsmargs, ...).foo(args, ...)

regards,
Rémi

[1] http://monge.univ-mlv.fr/ens/Master/M2/2016-2017/VM/index.php
    the main page is in french but not the different labs.