[foreign] RFR 8218153: Read/Write of Value layout should honor declared endianness

[Maurizio Cimadamore]

Another issue I thought overnight...

When invoking functions, especially with universal invoker, it is quite 
common to allocate temporary buffers - and then write to them using the 
Pointer API. We even have Pointers (in UniversalUpcallHandler) modeling 
register values, and we call Pointer::get on them.

The issue is - we said earlier that it will be 'forbidden' to access 
memory using a layout that has no endianness - but how exactly can we 
tell whether we're accessing memory or not? We can't just restrict all 
calls to Pointer::get - as some pointers will be based off containers, 
which have no notion of byte swapping and should just return the 
bit-image of whatever value is in them.

This seems to suggest that not all pointers are created equals - this is 
something we touched on briefly also when discussing scopes: the 
ownership model doesn't really apply to the region of temp memory 
allocated by the various invokers.

So it seems like invokers will need to allocate pointers carefully so as 
to avoid accidental errors (or accidental byte swapping) creeping in.

Maurizio

On 07/02/2019 23:13, Maurizio Cimadamore wrote:
>
> On 07/02/2019 22:13, John Rose wrote:
>> On Feb 7, 2019, at 1:19 AM, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com> wrote:
>>> If the replacement happens inside a function, the resolution 
>>> machinery will take care of 'stripping' endianness of the replaced 
>>> layout.
>>>
>>> This is doable of course, but it's more complexity (both in impl and 
>>> in terms of user model) - are we ok with it?
>> I'm OK with stripping endian-ness in specific situations
>> where the layout is being used in a container (i.e., a register)
>> rather than in memory.
>>
>> One way to think about this is that such a layout is being
>> used to specify a container, not memory.  Maybe there's
>> some rule here to tease out for deriving a container from
>> a layout?
>
> Yeah - I think the rules would amount at essentially stripping 
> endianness from value layouts; for groups, if a layout element 
> _inside_ the group has endianness, that has to remain in place. In 
> other words, the 'stripping' operation only affects outermost value 
> layouts being used as arg/return in a function descriptor.
>
> Maurizio
>