Limitations of the Calling Convention Optimization

[Brian Goetz]

Sorry, I wasn't suggesting "try changing your code this way and see if 
it works", as much as "if the user could code this way, could we infer 
what is going on, and put information in the classfile that can help the 
VM do the right thing at runtime."

On 10/21/2020 3:58 PM, Maurizio Cimadamore wrote:
>
> 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
>