On Apr 10, 2020, at 4:19 AM, [email protected] 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
