Lynn Quam wrote:
There are a number of subtleties in implementing the "static" arrays. The Allegro :ALLOCATION keyword argument to MAKE-ARRAY is interpreted as follows (taken from the Allegro 7.0 documentation):
|:static| or |:malloc| ||
Allocate the new array in malloc (foreign) space. The array will never be touched by the garbage collector and must be deallocated explicitly. Only a restricted number of element types are supported for static arrays. They are listed below. :malloc and :static are synonyms.
I believe this is what the is currently implemented using your foreign vectors. (Except there's no function to deallocate such vectors currently.) And they are vectors, not n-dimensional arrays. These are also no currently exported but could be if desired.
|:static-reclaimable|
Allocate the new array data in malloc (foreign) space and the header in Lisp space. The data will never be touched by the garbage collector but it will be deallocated when there are no pointers from Lisp (using a finalization). Only a restricted number of element types are supported for static arrays. They are listed below.
This is how the static vectors are implemented. A complex array header is allocated, and the data vector slot is the foreign vector (static/malloc vector above). We use a finalizer to free the foreign vector when the complex array header becomes garbage.
|| ||
|:lispstatic-reclaimable|
Allocate the new array in malloc (foreign) space. The array will never be touched by the garbage collector until there are no pointers from Lisp, at which point the whole array will be deallocated explicitly. Any Lisp type can be contained in the array.
This is not currently implemented. If any Lisp type can be contained in the array, we'll have to teach GC to scan the array elements in case a lisp object moves. And I'm not sure how to tell when such an array becomes garbage.
It is important to note the difference between |:static-reclaimable| and |:lispstatic-reclaimable|. I think that |:lispstatic-reclaimable is what needs to be implemented for CMUCL. |An array allocated as |:static-reclaimable| cannot be a simple-array in CMUCL since the array data does not immediately follow the header. Therefore, it is difficult to compile inline array accesses unless KERNEL::%WITH-ARRAY-DATA or kernel::%array-data-vector is used to get the actual data-vector. ||
Yes, the current static arrays are not simple-arrays. And n-dimensional arrays always have array headers, so inline access is never done in that case But some time ago I measured the difference between arrays with and without the array header and there was only a 10-25% (?) difference. (I think I compared 2D arrays, so perhaps that's not a good test.) Ray