[foreign-memaccess] RFR 8228444: Add common value layout constants

[Jorn Vernee]

On 2019-07-19 19:37, Maurizio Cimadamore wrote:
> On 19/07/2019 18:22, Jorn Vernee wrote:
>> I'm not sure I love the names either... 'BYTE_X_BE' seems to 
>> reminiscent of a Java (or C) byte. How about `V8_BE`, `V16_LE`, etc... 
>> ('V' standing for 'Value')?
> 
> I agree that BYTE is problematic here - I originally came up with
> 
> OCTET
> HWORD
> WORD
> DWORD
> 
> but wasn't sure of that either.

Well, DWORD is also a Windows API type which is 32 bits, a WORD is 16. 
HWORD here stands for 'half word' I guess, so 8? And then OCTET is 64?

Not super clear, since a 'word' can also have a machine specific 
meaning.

> Another option is to go "bitty":
> 
> BITS_8
> BITS_16
> BITS_32
> BITS_64
> 
> Which looks more agnostic.

This would work imho.

Any ways, I'm thinking that probably, in all but the ad-hoc use cases, a 
user will declare a static final ValueLayout with a name that makes more 
sense for that specific use case.

>> 
>> About the JAVA_XXX constant; maybe it's good to put these in a nested 
>> class as well, that way users can use a static import to import just 
>> the Java constants, they will be grouped together, and after all 
>> `JAVA_BYTE` is almost the same as `Java.BYTE`. (what do you think?)
> We could go there - don't feel too strongly either way - but I don't
> like too much nesting.

Yeah, it's a bike shed comment on my part. In the end it probably 
doesn't really matter.

Jorn

>> 
>> Also, it seems that TestMemoryAccess could use the Java constants 
>> instead of calling the factories, what gives?
> 
> Yeah - I will/can consolidate after I remove also the factories (see
> other patch)
> 
> Maurizio
> 
>> 
>> Jorn
>> 
>> On 2019-07-19 18:49, Maurizio Cimadamore wrote:
>>> Hi,
>>> this is a first stab at implementing a set of layout constants along
>>> the guidelines described in [1].
>>> 
>>> http://cr.openjdk.java.net/~mcimadamore/panama/8228444/
>>> 
>>> More specifically, the Layouts class introduces layouts constants to
>>> be used for language agnostic serialization, with explicit 
>>> endianness:
>>> 
>>> BYTE_LE, BYTE_BE, BYTE_2_LE, BYTE_2_BE, ...
>>> 
>>> And some Java-friendly constants whose endianness defaults to BE 
>>> (same
>>> as ByteBuffer):
>>> 
>>> JAVA_BYTE, JAVA_SHORT, ...
>>> 
>>> In the future, we will create nested interfaces here, one per
>>> supported ABI, with ABI-specific layout constants - e.g.
>>> 
>>> SysVABI.C_INT, SysVABI.C_LONG_DOUBLE, ...
>>> 
>>> This patch also removes endianness implicit constructors from
>>> ValueLayout - now endianness is always explicit (but if you use
>>> constants, you can ignore it, up to a point).
>>> 
>>> Overall this seems like the right mix of decisions - different
>>> constants, different users, different requirements. Not sure I 
>>> totally
>>> love the names, the challenge here is to find something that is
>>> relative semantics-neutral (since we plan to 'free' layouts from
>>> semantics considerations such as signed/unsigned int/float).
>>> 
>>> 
>>> [1] - 
>>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-July/006001.html