Limitations of the Calling Convention Optimization

[Maurizio Cimadamore]

On 21/10/2020 22:02, Brian Goetz wrote:
> 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."

And, my email came off wrong - the thought of covariant override 
occurred to me as well when writing the implementation - I think it has 
some legs (especially if the interface call can be devirtualized). But 
I'm still at a loss as to what can be done for parameter types (albeit, 
admittedly, the Panama API has far fewer examples in this category).

Maurizio

>
> 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
>>
>