On Apr 9, 2020, at 1:03 PM, Brian Goetz <brian.go...@oracle.com> wrote: > > >> I have a proposal for a translation strategy: > > Casts to inline classes from their reference projections will be frequent. > Because the reference projection is sealed to permit only the value > projection, a cast is morally equivalent to a null check. We want to preserve > this performance model, because otherwise we're reinventing boxing. > > Going through `ldc X.class / invokevirtual Class.cast` will surely be slow in > the interpreter, but also risks being slow elsewhere (as do many of the other > options.) > > So let me add to your list: is it time for a `checknonnull` bytecode, which > throws NPE if null, or some other more flexible checking bytecode? > (Alternatively, if we're saving bytecodes: `invokevirtual > Object.<nullcheck>`), where <nullcheck> is a fake method that always links to > a no-op, but invokevirtual NPEs on a null receiver.)
Um, this feels a lot like a premature optimization. Let’s not add `checknonnull` intrinsics to the interpreter (the very most expensive way to do it) until we have tried the other alternatives (Objects.requireNonNull, etc.) and have proven that the costs are noticeable. And a spec EG is not the place to evaluate such questions; it has to be demonstrated in a prototype. I see now why you are angling for verifier rules that know about sealing relations. I think that also is premature optimizations. Actually, verifier rules (not interpreter bytecodes) are the most costly way to get anything done. Sorry to be a party pooper here, but that’s how it looks right now. — John
