Limitations of the Calling Convention Optimization

[Brian Goetz]

So, confirming: we can have multiple calling conventions for a given 
method, but for a given _call site_, we choose a CC at linkage time and 
we have to stick with that.  Correct?

An "easy" case in Maurizio's library is something like this:

     sealed interface X permits Val { }
     primitive class Val implements X { }

     X makeVal() { return new Val(); }

Here, we are always returning a non-null Val.  So ideally, we'd like 
invocations

     Val v = makeVal()

to scalarize.  But the method descriptor is `()LX;`, and, at linkage 
time, we can't guarantee `X` has been loaded, which means we can't 
observe that Val is the only subtype of X.  So what you need is:

  - X and Val have to have been loaded at linkage time;
  - we need some confidence that `makeVal()` always returns a non-null 
value.

Does this capture what you're saying?



> Hi Brian,
>
> On 21.10.20 20:25, Brian Goetz wrote:
>> 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?
> With the current implementation, we would need the following information to scalarize interface
> arguments and returns:
> - A signal to load the type at method link time (John already elaborated on this [1]) and the
> information that it's a sealed interface with a single inline type implementor which also needs to
> be loaded.
> - A guarantee that the argument/return is null free OR the expectation that passing null will be
> slow (deoptimization -> execution in the interpreter).
>
> Best regards,
> Tobias
>
> [1] https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-October/008141.html