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

[John Rose]

On Jul 22, 2019, at 5:55 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
>> 
>> 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.

Right.  The way you are doing it is good.

>> 
>> 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.
> 
This sounds good.
> 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 :-)
> 

Right!  In terms of what I wrote previously, I suppose those commonalities are likely to pertain more to the *values* that are stored in memory (and elsewhere, such as argument lists), and not to the memory *containers* themselves.  Maybe there is also place for an abstraction like memory containers, but for non-addressable containers (registers, virtual and physical), and that abstraction might feature some but not all aspects of good old RAM.