Limitations of the Calling Convention Optimization

[Maurizio Cimadamore]

On 21/10/2020 19:25, Brian Goetz wrote:
>
>>
>> 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?
>
>
I tried this - I couldn't get it to work - the compiler complains if you 
try that.

Also, while this works for return types, it doesn't scale to parameters, 
right?

Maurizio