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

[Maurizio Cimadamore]

On 23/07/2019 00:00, John Rose wrote:
> On Jul 22, 2019, at 2:30 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>> * long, int, short, byte -> integer register
>> * float, double -> SSE register
>>
>> But we can't sadly, do much else. At least that's the conclusion I've 
>> reached when it comes to aggregates. Yes, we could have, in 
>> principle, different systems to communicate ABI info on different 
>> types - e.g. use carriers for scalar values, and use layouts for 
>> aggregates. But, if you go down that path, it still means that your 
>> layout must be able to capture the float vs. int distinction on its 
>> own (otherwise how do you classify struct { int x; } vs. struct { 
>> float f; } ?).
>
> You could go a little farther with carriers in structs by inspecting 
> the accessor signature for x and f.
Not really, unless you rely on some specialized carrier to be generated 
for the two structs. The name of the game, for this stage (low-level 
ABI) is: we can't depend on binder and, in general, on bytecode 
spinning. We don't want this level to introduce its own 'preferred' 
translation strategy - as doing so would severely limit usability from 
frameworks which might use alternate translation strategies.
>
> But I agree that relying only on carriers demands a lot from them, 
> which is why the “kind” attribute is part of the LDL document in the 
> first place.
>
> Turning a hard-wired “kind” property into a soft-wired annotation is 
> fine thing to do.
>
>> To solve this problem, there are two options: enhance the layouts 
>> with something like annotations - which is what I've described. 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.
>
> Yes; I agree.

Note - I'm not closing the door to having a closer-to-the-MH-machinery 
description that is, fundamentally, carrier-driven. But I want to 
generate the adapter MH that goes from the signature the user expects to 
the signature the ABI wants (which is a sequence of special carriers 
that linkToNative will know about) automatically.

And, to do that, I think the best way is to collect all the layouts for 
all the arguments, stick them into a 'function descriptor' (which is not 
a layout) and pass that one (along with a MethodType) to the SystemABI 
interface. If you have something like that, it is then possible to 
define an automated process which, given a function descriptor generates 
the required MH adaptations to match what the ABI/backend expect.

I'm not reusing layout sequences for argument lists. Functions are their 
own things - they are not layouts, just 'collection' of layouts: one 
optional return layout and a bunch of parameter layouts.

Moving forward it is possible that function descriptors and layouts will 
share some commonalities, such as the possibility to acquire 
annotations, but that does not make them a layout. With that I hope to 
have dodged the other siren song you talk about in your other email :-)

Maurizio

>
> — John
>