Limitations of the Calling Convention Optimization

[Brian Goetz]

>
> Unfortunately, the problematic idioms referred to in this thread shows 
> up quite a bit throughout the API; these are only some of the methods 
> which return new instances of these classes:
>
> For instance, in MemoryAddress we find the following methods:
>
> MemoryAddress addOffset(long offset); // returns _new_ address with 
> given offset from existing one
> static MemoryAddress ofLong(long value); // create _new_ address with 
> given long value

Let's try and invert the question.  Rather than beating up the JIT guys 
with "Y U no scalarize", let's ask: what information would the JIT need 
(and _when_) in order to routinely scalarize methods like this?

It seems that one part of it is knowing that these will never return a 
null reference.  Here's one way we might express this constraint in 
source code, using idioms the language already has:

     sealed interface MA permits Impl { MA offset(long offset); }

     primitive class Impl implements MA {
         @Override        // covariant override
         Impl addOffset(long offset) { ... }
     }

 From a language perspective, this makes sense to developers (and, this 
is hidden in the implementation); we're returning a more constrained 
type, which the language already allows.  Ignoring the translation story 
here (MA::offset and Impl::offset might have different descriptors, 
bridge methods, yada yada), would having information like this strewn 
throughout the implementation be sufficient to hint the JIT that no 
nulls will be forthcoming?