null checks vs. class resolution, and translation strategy for casts

[forax at univ-mlv.fr]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 9 Avril 2020 23:56:45
> Objet: Re: null checks vs. class resolution, and translation strategy for casts

> On Apr 9, 2020, at 2:31 PM, forax at univ-mlv.fr wrote:
>> 
>> yes, indy is a way to create any new bytecode, but it also has some
>> restrictions,
>> the major one being that you can not using it before it has been bootstrapped.
> 
> Good point; we found that with string concatenation, didn’t we?
> If we use indy for this, we’ll run into similar bootstrapping issues.

Replacing an inner class by a lambda when calling AccessController.doPrivileged early in the boot process was my first encounter with this issue.

> 
> Which reminds me that Brian has been pondering javac intrinsics
> for some time, as a way of replacing method calls that would
> ordinarily be linked and run the normal way, with preferable
> alternative implementations.  This game could also be played
> (very carefully) with BSMs.  That (like javac intrinsics) would
> sidestep the usual bootstrapping orders.

javac intrinsics doesn't work well because of profile pollution, by example with String.valueOf(), if the format is a constant, you can transform the format (if it is non Locale sensitive) to a string concatenation, but there is no way to express "if it's a constant" at indy level. Either you capture the format string and hope you will see the same, here you have a profile pollution issue or you have a magic combinator that say if it's constant use this method handle and not the other one but in that case, the method handle called if the argument is a constant has never been called and so has no profile further down.  

> 
> So, here’s a recommendation:  Use indy, and use a clunkier
> fallback in the same places that today use a clunkier fallback
> for string concatenation.  And, record a line item of technical
> debt that we should further explore indy intrinsics, after we
> figure out what javac intrinsics look like.

What is not clear to me is that javac can replace unbox by a nullcheck, for the VM, the input is an interface and the output is an inline type, given that interfaces are not checked until runtime, how the VM can validate that only a nullcheck is enough ?

Also it's still not clear to me what indy provide in this case. So i still think that doing a checkcast  (reusing checkcast being a trick to avoid to introduce a new bytecode) or having a special unbox opcode is a better idea. 

> 
> — John

Rémi