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

[John Rose]

On Apr 9, 2020, at 1:03 PM, Brian Goetz <brian.goetz at 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