From: Juho Snellman <jsnell@us...> - 2005-07-28 21:37:05
Update of /cvsroot/sbcl/sbcl/src/compiler/x86-64
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8850/src/compiler/x86-64
A bunch of GC changes that started to suffer from bitrot
before getting sufficiently mature to commit to HEAD. This
forward port to 0.9.3 seems to work, but hasn't been
The eventual goal of this branch is to have improved GC
latency, higher whole-system performance and
* The static space is a bad idea on gencgc, since it has no
write barrier. Make s-l-a-d default to not purifying on
* When loading a core, move the contents of the initial dynamic
space into the oldest generation.
* Allow doing the bits of purification related to manipulating
the info environment without doing a full purification. The
interface for this needs rethinking. Maybe always do the
compacting when s-l-a-d is called with :purify nil.
* Most iterations over the page table are only interested
in pages of one generation. After the static space has been
eliminated this becomes the major bottleneck in GC speed.
To speed this up, maintain a doubly linked list of the pages
in each generation.
* Abstract iterating over the page table with C macros.
* Make MAP-ALLOCATED-OBJECTS take advantage of the page table
on gencgc, for better performance and more accuracy.
* When saving a core without purification, do a
* Add some typedefs for GC stuff like page table / generation
table indices, and try to use these types consistently
throughout the gencgc.
* Some misc. x86-64 cleanups.
To be done before this is fit for HEAD:
* Even though the s-l-a-d non-conservative GC is as efficient
at clearing out the unwanted bits as purify, it doesn't
properly compact memory. The core files are therefore about
two times bigger than they should be. Something clever needs
to be done here.
* Merge some bits from another tree that replaces the current
"munmap/mmap to zero pages lazily when GC frees them" behaviour
with "memset when pages are allocated to newspace". This might
* Test on x86.
* Check that the linked list manipulations are thread-safe.
* Rethink the changes to the purification interface.
RCS file: /cvsroot/sbcl/sbcl/src/compiler/x86-64/parms.lisp,v
retrieving revision 1.10
retrieving revision 188.8.131.52
diff -u -d -r1.10 -r184.108.40.206
--- parms.lisp 14 Jul 2005 19:13:49 -0000 1.10
+++ parms.lisp 28 Jul 2005 21:36:51 -0000 220.127.116.11
@@ -96,7 +96,9 @@
(def!constant static-space-end #x47fff000)
(def!constant dynamic-space-start #x1000000000)
-(def!constant dynamic-space-end #x11ffff0000)
+;; XXX XXX temporarily make the dynamic space smaller while hacking the GC.
+;; I don't want to kill the whole computer every time I introduce a GC bug.
+(def!constant dynamic-space-end #x101fff0000)
(def!constant linkage-table-space-start #x60000000)
(def!constant linkage-table-space-end #x63fff000)
@@ -207,6 +209,9 @@
+ ;; For GC-AND-SAVE
;; The ..SLOT-UNBOUND.. symbol is static in order to optimise the
;; common slot unbound check.