Limitations of the Calling Convention Optimization

[Maurizio Cimadamore]

On 23/10/2020 07:51, Tobias Hartmann wrote:
> We can speculate but the question is how do we handle null if it still shows ups? The easiest way
> would be to just deoptimize but then performance will suck whenever null is passed.

Just a quick note: from an API observation (and of course we need more 
experiments and data), this might not be as horrible of a compromise as 
it sounds. If you think of a factory like this:

Point makePoint(int x, int y); // Point is an interface

which is implemented in the usual way like:

Point makePoint(int x, int y) {
     return new PointImpl(x, y); // PointImpl is an inline 
implementation of Point
}

Nulls here are simply not possible, by construction. As my experiment 
with Panama API show, this is a common idiom when you work with 
immutable classes with lots of "withers".

But it works the other way around too - consider:

double distance(Point p1, Point p2);

E.g. I would expect the vast majority of the arguments to be 
null-checked on the way in (Objects.requiresNonNull(p1)).

So, my point is that, if we take a slow path when a null is encountered, 
it might not matter _that_ much because we're about to throw an NPE anyways.

Of course this assumption needs to be validated with hard(er) data.

Maurizio