[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