[foreign-memaccess] RFR 8228447: Remove kinds from value layouts

[Maurizio Cimadamore]

On 22/07/2019 10:30, Maurizio Cimadamore wrote:
> Or we could enhance the carrier system to cover aggregates - e.g. 
> StructWithOneInt.class - but if you look at the ABI (esp. SysV) there 
> are so many combinations to pass small structs into registers that 
> having one single carrier for each combination is just overkill. And, 
> needless to say, such carrier would end up replicating some of the 
> structural info already available in the layout. 

Btw, here I considered four alternatives:

1) keep using float, int carriers for scalars; aggregates are 
represented using new carriers e.g. STRUCT_INT_FLOAT - where we have one 
carrier for each classification combo

1b) As (1), but let client manually recursively classify aggregates and 
pass them as a sequence of 64-bit words (e.g. longs, or doubles)

2) use carriers to model ABI register families - so, floats will be 
passed using some SSE carrier; the number of combination of carriers for 
aggregates is greatly reduced, but all primitives have to be 'boxed'

2b) As (2), but let client manually recursively classify aggregates and 
pass them as sequences of register carrier values

No doubt something like (1b), (2) or (2b) could work. But I highly doubt 
that developers (even low level ones) will want to interact with such 
flattened low-level method handles. Even existing FFI libraries (e.g. 
libFFI) don't do this far.

So, if we went down this path, we would _still_ need something that 
bridges the gap between the developer understanding of a signature and 
the ABI understanding of same signature (e.g. a MH adapter). How do we 
adapt? Here is where I feel we're back to square one. We need to invent 
a description that is general enough to capture all the details the ABI 
care about. But if we have layouts, why not doubling down and reuse those?

In other words, I totally buy that, if we use Layouts to covey 
information about ABI classification might or might not be a primitive, 
and there is a more low level way to think about these things. At the 
same time I'm playing a lumping move here, and saying that thinking 
about the uber FFI low-level in isolation doesn't seem to carry much 
value. Where I see it adding value is when a developer would like to 
model a custom ABI - but this is a very advanced use case, and I could 
not find a single framework able to cope with such generality (see LLVM 
discussion linked previously). So, maybe one day we'll want to go down 
that path - fine; using layouts as a source of truth for ABI 
classification is (i) a forced move in order to provide a slightly more 
friendly FFI integration and (ii) doesn't preclude us to add an 
intermediate layer down the road.

Maurizio