New draft JEP: intrinsics for String::format and Objects::hash (among others)

[Remi Forax]

[move to amber-spec-experts]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Lundi 22 Octobre 2018 21:45:00
> Objet: New draft JEP: intrinsics for String::format and Objects::hash (among others)

> For those of you following the saga of improved constant folding, which
> includes JEPs 334 and 303 (see
> https://www.youtube.com/watch?v=iSEjlLFCS3E), another installment of the
> story ...
> 
>     https://bugs.openjdk.java.net/browse/JDK-8205637
> 
> While JEP 303 provides intrinsics for pseudo-methods (ldc,
> invokedynamic) whose semantics will be spelled out in the JLS, this JEP
> provides for more ad-hoc transformation of method invocations to
> LDC/indy, and outlines the initial candidate for this treatment
> String::format and Objects::hash.  (It does not rely on the constant
> folding and propagation that JEP 303 relies on, and so can be delivered
> before those are.)  The initial scope is deliberately limited; it can be
> expanded later.
> 
> We're working on some performance numbers that will provide the context
> on why we chose these particular methods -- these will be added to the
> JEP when ready.


I've recently discovered that the latest version of Eclipse is using Objects.hash() by default when you ask to auto-generate the hashCode,
obviously this is plainly wrong because the current implementation does a lot object allocations, but at the same time, the code is more readable.
So +200 on this JEP !

Now, the issues i see.
if you translate the bytecode, you are loosing the call to String.format() so if there is a NPE because one of the parameter is null, String.format() will disappear from the stacktrace of this NPE. 

Also, from the point of view of the bytecode analyzers that do an abstract execution of the bytecode (Jacoco, Findbugs, Proguard, any IDEs, etc) each of them will have to have a mechanism to go from the invokedynamic call to the original call so it an be interpreted. It's seem to be a waste of resources to not a standard way to get the original call at bytecode level.  

Limiting these intrinsics to the JDK methods has a big drawbacks, it makes the performance model less easier to understand.
By example, String.valueOf() will be fast but the method debug(String format, Object...) of a LOG4J Logger will be slower (even if it changes its implementation to use String.format internally because the format parameter will not be constant inside the implementation).

I understand that you do not want to open the pandora box of offering a macro system to everybody, but i hope there is a knd of middle ground, here, perhaps by enabling any methods to use the instrinsics annotation but to limit the bootstrap methods that can be used to the ones defined in the JDK. 

To summarize,
- i think the bytecode should contains the information indicating the original call.
- users should be able to use the annotation given that the meta factory is restricted be in declared in java.base. 

regards,
Rémi