[foreign-memaccess] on value kinds
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Jul 16 23:40:17 UTC 2019
On 16/07/2019 23:22, Jorn Vernee wrote:
> We'd not need to infer anything, we'd explicitly encode all the needed
> information. One advantage is that we could choose what's in a
> function description specifically geared towards supporting C. Support
> for another language could choose to have it's own function descriptor
> with more/less captured information. But the point in the scope of
> this discussion is that we don't have to try too much to support all
> the C ABI (and down the line other ABI) semantics with the Layout API.
Since we're talking about short vs. long term, in the longer term we
have discussed internally to enhance linkToNative in two ways - which, I
think overlap a lot with what you propose:
* provide an API to allocate and manipulate stack memory (stack memory
segments??) from Java
* provide a set of lightweight (possibly via Valhalla) carriers with
specific ABI semantics which linkToNative will understand. For instance,
a struct passed by pointer in Windows will use a special argument type.
So will an x87 value on SysV and also multi-return values on SysV. In
other words, SystemABI is about layouts + method types: we have squeezed
the heck out of the layout part of the equation - it is now time to do
the same with the method type part of the equation.
That said, as you can see, something like this has a non trivial cost;
we're talking about new APIs (for writing on stack), and we are adding
critical dependencies on Valhalla (there's no way we can get decent
performances if these little ABI-specific carriers are not inline
classes). Which is why, even though we'll end up building something like
that eventually, I feel at the same time that we should find alternate
ways to solve the specific problems we're facing. Whether that means
applying (too) clever tricks to layouts or inventing something else of a
temporary nature - we clearly need _some_ way past the hurdles we're
facing for the C ABI.
Attaching ABI-dependent annotations to layouts is super-easy, basically
works with the existing machinery - and can address both issues like x87
and issues like varargs in Windows; it also builds up on the same
concepts that are introduced by the memory access API - making it easier
for users. Which is why I have been attracted by the idea.
Maurizio
More information about the panama-dev
mailing list