[cmucl-imp] Re: Static array support

[Lynn Quam]

Many years back, Jon L White at Lucid Inc considered a new array 
declaration which would allow the inlining of non-simple arrays.  The 
declaration form was

  (declare (type (non-simple-array <element-type> <bounds>) . <vars> ))

The compiled code would always assume that the array was non-simple, and 
indirect thru the array header to find underlying array.  I do not 
remember all of the details and limitations, except that the underling 
simple-vector could always be found with only one indirection. 

Raymond Toy wrote:
> 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
>
>
>