More detail than I had intended on Layout description language

[Tobi Ajila]

>> > Was I correct in seeing that it is proposed to attach LDL to
>> > interfaces with annotations?
>>
>> Yes, we proposed this. However, we're certainly open to alternatives.
>>
>> Since LDL is not platform-independent, if the LDLs are attached to the
generated Java interfaces, then the Java interfaces are also not
platform-independent. Is this is good or bad?

>Normally I?d say bad.

At this point we feel that the LD should not be attached to the generated
Java Interfaces as it would make things more difficult for developers who
support multiple platforms. Keeping the interface and the LD separated
would allow developers to have one copy of the generated interface checked
into their source control.  Users will need to manage the LD files for all
supported platforms.


>It might be interesting to try to see what happens with network protocols,
>which are ultimately (at the byte-by-byte level) unambiguously specified.
>That gets in the way of the platform-independent Java-behavior story,
>because I can easily imagine that what you like to have happen in the
generated
>code is something like a loadInt, and on wrong-byte-order platforms, a
byte-swap.
>I was thinking ?network protocols? because those are something that we
really
>do expect to see on more than one platform.

We view the LD as two streams of data. A stream that contains layout data
such as sizes and offsets, and a stream that carries type data such as
name, sign/unsigned, integral/float. Endianness would be part of the type
stream and it would be up to the runtime generated class to do the endian
swapping.

I would also add, the endian attribute would be an absolute value (big or
little). We could have a shorthand to specify endianness for an entire
Layout, but field specification should always take precedence.

>would at least give us a prayer of saying that the same generated proxies
would work across platforms

We've been viewing the generated proxies as something that is generated at
runtime when an LD is read in. This would be platform dependent.

>If you are references-only, then it?s all aliased.  Suppose you wanted to
rotate the
>vertices of the triangle, say

>  Triangle tri = someNativeThing.get Triangle()
>  Array<Point> points = tri();
>  Point t = ??I need to make a copy here?? (points.get(0));
>  points.get(0).set(points.get(1));
>  points.get(1).set(points.get(2));
>  points.get(2).set(t);

>So what happens to make that copy?   I think there are (at least) 3
choices
>that are not even mutually exclusive:

I think we prefer 1)a). "Native heap" could mean many things such as RDMA,
GPU mem, etc. This would introduce many challenges. Unless we make on-heap
copies in this case, we would need a way to allow the user to provide a
custom allocator (and memcpy) to manage their "native heap".

>The other point I wanted to toss in, is that once you put alignment into
the mix
>and not just as an ?oh yeah, we need to think about alignment? it might
change
>how we talk about some of the other stuff.  If you look at C bitfields,
there is very
>much a model of ?load a box this big, then shift the data towards the low
order
>bits some distance, then mask/sign-smear the part we don?t care about?.

We think that specifying alignment is important in the context of start
allocation for a layout type. Start alignment should be externalized for
the benefit of implementing allocators for standalone instances of the
layout data. But in terms of field alignment within a layout (this is
includes bit fields and nested layouts) we feel that alignment must be
specifically declared in the form of padding and not the start alignment
attribute. It is the job of the groveller to determine what the required
field alignment/padding is on a given platform and the resulting LDL should
be very explicit about that.

For example:
struct c {
     unsigned short x:1;
     unsigned short y:7;
};

on Big endian

LD: "c",":8","y:7","x:1"

on Little Endian

LD: "c","x:1","y:7",":8"