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.r...@oracle.com> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@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.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
