From: Daniel Barlow <dan_b@us...> - 2003-09-02 00:08:51
Update of /cvsroot/sbcl/sbcl/src/compiler/sparc
In directory sc8-pr-cvs1:/tmp/cvs-serv31629/src/compiler/sparc
Exciting gencgc hacking: SB-SYS:WITH-PINNED-OBJECTS
When passing Lisp objects to foreign code, it is important
that GC doesn't change the object's address as the foreign
code's pointers to it won't be updated. Traditionally this is
done using WITHOUT-GCING, but that's not ideal in a threaded
system where one thread may be doing a blocking alien call and
other threads would like to continue as normal.
So, instead we shove pointers to the important objects on the
C stack where they will cause the pages pointed to to be
pinned in place using preserve_pointers. Additionally we make
a small change to gencgc to ensure that they _stay_ pinned in
On ports that use cheneygc we can't do this, so
WITH-PINNED-OBJECTS is just an alias for WITHOUT-GCING. As
these ports don't have threads anyway, that's not a major
Small updates to doc/internals-notes/threading-specials,
slightly larger updates to comments regarding ALLOCATION
and PSEUDO-ATOMIC macros
Documentation update to the FFI chapter
RCS file: /cvsroot/sbcl/sbcl/src/compiler/sparc/macros.lisp,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- macros.lisp 3 May 2003 18:28:12 -0000 1.8
+++ macros.lisp 2 Sep 2003 00:08:15 -0000 1.9
@@ -224,3 +224,13 @@
(inst andcc zero-tn alloc-tn 3)
;; The C code needs to process this correctly and fixup alloc-tn.
(inst t :ne pseudo-atomic-trap)))))
+(defmacro sb!sys::with-pinned-objects ((&rest objects) &body body)
+ "Arrange with the garbage collector that the pages occupied by
+OBJECTS will not be moved in memory for the duration of BODY.
+Useful for e.g. foreign calls where another thread may trigger
+garbage collection. This is currently implemented by disabling GC"
+ (declare (ignore objects)) ;should we eval these for side-effect?