[cmucl-imp] Re: Static array support

[Raymond Toy]

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