1.0.28.24: better %ARRAY-DISPLACED-FROM handling
authorNikodemus Siivola <nikodemus@random-state.net>
Thu, 7 May 2009 11:11:05 +0000 (11:11 +0000)
committerNikodemus Siivola <nikodemus@random-state.net>
Thu, 7 May 2009 11:11:05 +0000 (11:11 +0000)
commita0238f83af553a3ff662824fc73aca3ba01112f6
tree25f3fe0c941bc4a973ce902c83870c04918156d6
parent48e457d13eb661a702f4f4f1cfd7a0bb7a57399a
1.0.28.24: better %ARRAY-DISPLACED-FROM handling

   James Knight pointed out that signalling an error at ADJUST-ARRAY
   time is not quite right, since the other array may be otherwise
   unreachable already -- we're following a weak pointer after all.

   Oops. Enter the twilight zone between clever by half and slightly
   horrible:

   When a potentially bogus ADJUST-ARRAY is detected, walk the chain
   of backpointers, and set FILL-POINTER, AVAILABLE-ELEMENTS, and
   all dimensions of the too-large displaced-from arrays to zero.

   This in turn causes any typecheck involving the array dimensions
   to trap, as well as any bounds-checked access.

   To make these errors more understandable, save the original
   dimensions of the array, punning them to the ARRAY-DISPLACED-P
   slot, and identify the bogus arrays in INVALID-ARRAY-INDEX-ERROR
   function, and the OBJECT-NOT-TYPE-ERROR internal error handler;
   signal an INVALID-ARRAY-ERROR instead, which explains what is going
   on.

   Whew.

   Oh, and a BIG THREAD SAFETY NOTE regarding the fundamental nature
   of our ADJUST-ARRAY implementation. It is not thread safe in
   parallel with accesses to the array being adjusted. Tentative
   idea is to add one more level of indirection to array headers,
   so that we can get atomic updates without locking.
package-data-list.lisp-expr
src/code/array.lisp
src/code/condition.lisp
src/code/interr.lisp
src/code/pred.lisp
src/compiler/generic/objdef.lisp
tests/array.pure.lisp
version.lisp-expr