value type hygiene

[Remi Forax]

----- Mail original -----
> De: "Roland Westrelin" <rwestrel at redhat.com>
> À: "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Jeudi 17 Mai 2018 16:27:02
> Objet: Re: value type hygiene

> [moving to valhalla-dev]
> 
> When it comes to the calling convention, there's one extra bit of
> complexity: method handles. For a method handle invoke to a method m()
> with value arguments, there will be a lambda form with a call to a
> method handle linker. If the LF is compiled as a standalone compiled
> method, the JIT has no way to know values are expected by the method
> that's behind the linker method so it passes buffered values. If method
> m() is JIT'ed so it's expecting scalarized values, the method handle
> call fails.
> 
> That problem is not specific to Lworld. It exists in MVT with
> __Value. We never solved it. But from previous discussions, it seems the
> way to solve that problem is for every method with value arguments to
> have 2 entry points: a scalarized values entry point and a buffered
> values entry point. In a first implementation, the buffered values entry
> point could fall back to the interpreter and the scalarized values entry
> point be eventually a JIT'ed method.
> 
> Now assuming we have to have 2 method entry points, why not use the
> buffered value entry point when one of the value arguments is null (or
> maybe null)? What entry point to use at a call site could be decided at
> JIT compilation time: either all arguments are statically known to be
> non null and we can go with the scalarized values entry point or we fall
> back to the buffered values entry point. Whether the code being JIT'ed
> is legacy or not doesn't factor explicitly in the decision.

yes, that's the other solution, either you decide to use a signature (the first time you introduce a signature in the v-table) as proposed by John or you have a generic version and a specialized version. The former avoid to buffer every value types just because one may be null the later avoid weird NPE due the fact that a signature in a super type use a value type. 

Given that NPEs only arrive due to separate compilation, i'm not sure which option is the best.

> 
> Roland.

Rémi