considering the LDL

[Tobi Ajila]

> And what is the highest-leverage place to include
> concepts like endian, volatile, atomic, immutable, alignment,
> explicit offsets, bit-slices, and memory blocking factors?

If we want to keep the LDL minimal, the criteria for inclusion
should be concepts that deal with memory layout. Endian-ness
would meet this criteria because in multiple byte scalars it
determines memory layout. Similarly, offsets (and or size
depending on notation) should also be in the LDL as they
provide layout information.

Alignment is an attribute of a member in a layout. It is also
important to know alignment when doing allocations or binding
to memory allocated by native code. For these reasons I think
alignment should be in the LDL. So what kind of alignment
constraints do we need?

> The nest becomes more interesting if you add more
> constraints on formation.  For example, the alignment
> of the parent must satisfy the alignment of all the children,
> in the obvious way.  Imposing this constraint will force
> C-like structs to "grow" padding, if their children have
> alignment constraints.  Or it will force the children to
> lose their constraints. There's no one right answer, so it
> has to be an option.

If we specify alignment constraints for every
child member within in a nest. Using the rule, "the alignment
of the parent must satisfy the alignment of all the children,
in the obvious way" we have the following:

//Based on child members alignment of A is 4 bytes
struct A {
	uint16_t x;     //natural alignment of 2 bytes
	uint32_t y;     //natural alignment of 4 bytes
}

Here is another example:

//Based on child members alignment of PackedA is 2 bytes
struct __attribute__((__packed__)) PackedA {
	uint16_t x;     //natural alignment of 2 bytes
	uint32_t y;     //has natural alignment of 4 bytes but in this
					//nest it's aligned to 2 bytes
}

The last example would suggest that the children should lose their
constraints, but one could argue the opposite.

A simpler alternative that doesn't require the user to make a
choice (configure the tool) would be to say, all parent and
child alignment constraints must be expressed by explicit field
offsets (for the children) and a start alignment (for the parent).
All possible compositions must be specified in this manner. The
start alignment only applies to allocations of its type. It does
not apply when the type is nested in another parent (child has no
alignment constraints only explicit offset).

The native side determines the alignment constraints of fields
(when to keep them and when to lose them), our tool should not
do this. It should only respect the constraints set by the native
side.

The benefit of this approach is that the offsets are always
explicit and we don't need padding rules. We only need to test the
EA with the start alignment of the composition. This also lets us
specify over-alignment in certain cases.

Atomicity, volatility and immutability are properties of
access not of memory layout. For this reason I would argue
that they should be omitted from the LDL. However, if they
are not in the LDL then where should they go? Ideally they
would be in a layer above the LDL. Using VarHandles to
build accesses on top of layouts would be an interesting option.
This would let us decouple accesses from layouts while
taking advantage of the many accesses provided by
VarHandles.

Memory blocking factors (and other compiler hints) don't
really provide any layout information and they  mostly
apply to data authored by Java. I think this should also
be omitted from the LDL. But, just as in the previous case,
if its not in the LDL then where should it go? Do you have
any ideas for encoding information that is not layout
related?

Regards,
--Tobi