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

[Remi Forax]

I don't fully understand why not using checkcast because from the user POV the message will be better than just NPE.

Rémi

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 9 Avril 2020 22:16:06
> Objet: Re: null checks vs. class resolution, and translation strategy for casts

> 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