Re: Quesition about Lisp_Vector

[Ken Raeburn <raeburn@raeburn.org>]

On Nov 11, 2011, at 22:42, Stephen J. Turnbull wrote:
>> a long time, and it works on most if not all C compilers.
> 
> clang (llvm) warns about accesses with a constant index greater than
> zero, but it works.

Good point.  In terms of complaints, I was thinking more about the detection of run-time indexes greater than zero.  I've used one implementation that either interpreted C or compiled with extensive run-time checks (not that it matters which), that probably would've flagged the reference at run time for checking, but I don't recall for sure.  (It was a couple decades ago.)  I expect something like valgrind wouldn't have enough information to detect it.

> Ah, now that interests me.  If there actually is such space, most
> constant index accesses are to a[1], and in theory we could allocate
> array space to fill out the padding.  However, since the structure
> alignment requirement is usually no more than sizeof(pointer), which
> is the same as sizeof(Lisp_Object), and IIRC all of the Lisp_Vectors
> warned about are general (ie, the elements are Lisp_Objects), we
> probably don't buy anything.

Right, in practice in this case it's not likely to save us anything on most platforms.  But an implementation could have rules like "structures over 8 bytes get 16-byte alignment" (assuming 32-bit pointers), in which case there would be wasted space at the end.  On the other hand, the rules could also say that larger arrays get stricter alignment, which (in other use cases, probably not this one) could cause an attempt to utilize that extra space to instead introduce padding before the array.

The C99 spec for flexible array members is even written to give the implementation some flexibility regarding this; it can place the member as if it has some unspecified size chosen by the implementation, with the alignment and padding rules following from that choice.

> I wonder if there is any real loss to allocating two or three elements
> in the base structure (ie, how often vectors of length less than three
> or four are used).

Instrumenting the GC code would be an easy way to find out how many are live at any given GC point, assuming the size fields don't lie.

Ken