Variable length arrays in Layouts

[Angela Lin]

If we think VLA's should be handled by Layouts, the main conceptual
question
we've raised is whether we should consider the "length" field of a VLA to
be
immutable, and how/if we should handle potential modification or corruption
of
this field.

This question is captured in this part of
http://j9java.github.io/panama-docs/VariableLengthArrays

> 5.1) Is the repeat count field writable?
>
> * yes
>   makes it easy to construct a Layout containing a VLA as it makes it
possible
>   to write in the length after the layout is bound to memory
>
> * no
> makes it easier to verify that VLAs remain within the bounds that they
were
> allocated in would be easier to optimize increases API complexity (why
are
> some fields read-only and others aren't?)
>
> * yes, but keep track of original repeat count length (capacity)
> would be useful in cases where the user wants to track capacity and fill
count
> separately makes it possible to verify that array doesn't exceed original
> bounds introduces memory overhead
>
> Answer:
> The repeat count field is read-only. The behaviour of the simple case
should
> be consistent with future extensions (ie. VLA followed by VLA). Allowing
the
> repeat count field to be writeable would make it possible to introduce
gaps in
> the layout or overflow memory allocated for the VLA.
>
> ---------------------------------------
> Question to Spec Group:
> Should we track capacity or not?
> In Java there are many ways to alias data. Even if we make the repeat
count
> field read-only by only generating getters for it, it doesn't guarantee
that
> the value will not be modified by other means. Keeping track of capacity
would
> help to protect against cases where aliasing could cause modification of
data
> that leads to overflows, but this increases memory overhead.
> ---------------------------------------

In my opinion, it does not make sense to track the capacity since there is
no
correct way to do it. To be effective, the capacity must be immutable. If
you
put the capacity in the data itself, then you can't protect its
immutability if
the data is aliased.  If you don't put the capacity in the data, then you
can't
construct it correctly from just the data. Consider this sequence:

1. Bind a layout, Layout A, to memory that looks like this:
struct {
    int length = 10;
    int tail[10];
} exampleA;

Layout A stores a capacity of 10.

2. set exampleA.length = 8

3. Bind another layout, Layout B, to the same memory.  Layout B stores a
capacity of 8, then? This is inconsistent.