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

[John Rose]

On Apr 10, 2020, at 4:19 AM, forax at univ-mlv.fr wrote:
> 
>> 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 ?

It can’t; that’s why I’m saying javac needs to ask for a null check,
*and* somehow affirm the inline type (subtype of interface).
This is two bytecodes, invokestatic Objects.requireNN, plus
checkcast C.

> Also it's still not clear to me what indy provide in this case.

It provides both of the above effects in one bytecode.  The bytecode,
in turn, can expand to some internal JVM intrinsic which the runtime
will optimize better than a back-to-back combo of the two standard
instructions.  That intrinsic never has to be admitted to by any spec.

> 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. 

Changing opcode behaviors and/or adding new opcodes is always
more expensive than appealing to indy, even if we have to add secret
optimizations to indy.  Specs are almost always harder to change than
optimizations.

— John