SPARC gencgc
[sbcl.git] / src / assembly / sparc / array.lisp
index 1bd9e20..926550b 100644 (file)
                           (:res result descriptor-reg a0-offset)
 
                           (:temp ndescr non-descriptor-reg nl0-offset)
+                          (:temp gc-temp non-descriptor-reg nl1-offset)
                           (:temp vector descriptor-reg a3-offset))
   (pseudo-atomic ()
-    (inst or vector alloc-tn other-pointer-lowtag)
     ;; boxed words == unboxed bytes
     (inst add ndescr words (* (1+ vector-data-offset) n-word-bytes))
     (inst andn ndescr 7)
-    (inst add alloc-tn ndescr)
+    (allocation vector ndescr other-pointer-lowtag :temp-tn gc-temp)
     (inst srl ndescr type word-shift)
     (storew ndescr vector 0 other-pointer-lowtag)
     (storew length vector vector-length-slot other-pointer-lowtag))
   ;; This makes sure the zero byte at the end of a string is paged in so
   ;; the kernel doesn't bitch if we pass it the string.
+  ;;
+  ;; RLT comments in CMUCL about changing the following line to
+  ;; store at -1 instead of 0:
+  ;;   This used to write to the word after the last allocated word.  I
+  ;;   (RLT) made it write to the last allocated word, which is where
+  ;;   the zero-byte of the string is.  Look at the deftransform for
+  ;;   make-array in array-tran.lisp.  For strings we always allocate
+  ;;   enough space to hold the zero-byte.
+  ;; Which is most certainly motivated by the fact that this store (if
+  ;; performed on gencgc) overwrites the first word of the following
+  ;; page -- destroying the first object of an unrelated allocation region!
+  ;;
+  ;; But the CMUCL fix breaks :ELEMENT-TYPE NIL strings, so we'd need a
+  ;; branch to figure out whether to do it.  Until and unless someone
+  ;; demonstrates that gencgc actually gives us uncommitted memory, I'm
+  ;; just not doing it at all:  -- DFL
+  #!-gencgc
   (storew zero-tn alloc-tn 0)
   (move result vector))