----- Mail original ----- > De: "John Rose" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "Brian Goetz" <[email protected]>, "valhalla-spec-experts" > <[email protected]> > 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, [email protected] 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
