value type hygiene

Roland Westrelin rwestrel at redhat.com
Thu May 17 14:27:02 UTC 2018


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

Roland.



More information about the valhalla-dev mailing list