Smaller stack frames on x86oids

[sbcl.git] / src / compiler / x86 / backend-parms.lisp

diff --git a/src/compiler/x86/backend-parms.lisp b/src/compiler/x86/backend-parms.lisp
index 44e0634..16ea497 100644 (file)
--- a/src/compiler/x86/backend-parms.lisp
+++ b/src/compiler/x86/backend-parms.lisp
@@ -27,7 +27,13 @@
 ;;; code for it, but mostly we need it for GENESIS, which doesn't in
 ;;; general have our C runtime code running to ask, so instead we set
 ;;; it by hand. -- WHN 2001-04-15
-(setf *backend-page-size* 4096)
+;;;
+;;; Actually any information that we can retrieve C-side would be
+;;; useless in SBCL, since it's possible for otherwise binary
+;;; compatible systems to return different values for getpagesize().
+;;; -- JES, 2007-01-06
+(eval-when (:compile-toplevel :load-toplevel :execute)
+  (setf *backend-page-bytes* 4096))
 ;;; comment from CMU CL:
 ;;;
 ;;;   in case we ever wanted to do this for Windows NT..
@@ -37,4 +43,17 @@
 ;;;   page size is 512, but that doesn't do us a whole lot of good.
 ;;;   Effectively, the page size is 64K.
 ;;;
-;;;   would be: (setf *backend-page-size* 65536)
+;;;   would be: (setf *backend-page-bytes* 65536)
+
+;;; The size in bytes of GENCGC cards, i.e. the granularity at which
+;;; writes to old generations are logged.  With mprotect-based write
+;;; barriers, this must be a multiple of the OS page size.
+(def!constant gencgc-card-bytes *backend-page-bytes*)
+;;; The minimum size of new allocation regions.  While it doesn't
+;;; currently make a lot of sense to have a card size lower than
+;;; the alloc granularity, it will, once we are smarter about finding
+;;; the start of objects.
+(def!constant gencgc-alloc-granularity 0)
+;;; The minimum size at which we release address ranges to the OS.
+;;; This must be a multiple of the OS page size.
+(def!constant gencgc-release-granularity *backend-page-bytes*)