emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Quesition about Lisp_Vector


From: Ken Raeburn
Subject: Re: Quesition about Lisp_Vector
Date: Sat, 12 Nov 2011 20:02:10 -0500

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]