Commit c40b7a6b authored by Raymond Toy's avatar Raymond Toy
Browse files

Fix #40: Move start of heap space higher

This is a workaround for issue #40.  By moving the start of the heap
to a higher address, we can still run on older systems (albeit with
reduced max heap size), and run on newer systesm where the C code is
now mapped at or overlapping the (old) heap start.  Arbitrarily choose
0x60000000 as a compromise.

This also requires moving the foreign linkage start to a different
address because the old address overlaps the new C area.

Ideally, we could fix this if we could map the heap wherever the OS
wants to put it, but we're not there yet.

Use boot-2017-04.lisp to bootstrap this change from the 2017-04
parent 2830e140
;; Bootstrap file for linuu to move the heap to a higher address so
;; that executables will work on newer OSes, as mentioned in issue
;; #40.
;; Use "bin/ -B boot-2017-04" to build this.
;; Also need to move the foreign linkage start to a different address
;; because this also overlaps where the C code is placed in an
;; executable image.
;; This reduces the max total heap space on older systems, but it
;; looks like newer systems have the C libraries and stack mapped at a
;; much higher address.
(setf (c::backend-foreign-linkage-space-start c::*target-backend*)
(defconstant vm::target-foreign-linkage-space-start
(c:backend-foreign-linkage-space-start c::*target-backend*))
(defconstant vm::target-dynamic-space-start
......@@ -64,7 +64,7 @@
(setf (backend-page-size *target-backend*) 4096)
(setf (c::backend-foreign-linkage-space-start *target-backend*)
#+linux #x58000000
#+linux #x5f000000
#+solaris #x30000000
#-(or linux solaris) #xB0000000
(c::backend-foreign-linkage-entry-size *target-backend*)
......@@ -235,7 +235,7 @@
#+FreeBSD #x28F00000
#-FreeBSD #x28000000)
(defconstant target-dynamic-space-start
#+linux #x58100000
#+linux #x60000000
#+solaris #x40000000
#-(or linux solaris) #x48000000)
(defconstant target-foreign-linkage-space-start
......@@ -37,6 +37,24 @@
* However, Fedora 22 ther appears to be nothing mapped there. In
* fact it appears to be free all the way to 0xf7c1b000. That would
* allow a heap of size 2555 MB.
* On even newer OSes like Ubuntu 17.04, the map looks something like
* 0x00000000->0x10000000 128M ?
* 0x10000000->0x20000000 256M Read-Only Space.
* 0x20000000->0x28000000 128M Binding stack growing up.
* 0x28000000->0x38000000 256M Static Space.
* 0x38000000-> ?
* 0x56555000-> C space
* 0xf7dfe000-> [anon]
* 0xf7e00000->0xf7fb4000
* 0xf7fb5000->0xf7fd9000 [anon]
* 0xf7fd9000->0xf7ffd000
* 0xfffdd000-> [stack]
* There's a potential clash if the lisp heap is mapped near
* 0x58100000 as shown above. This happens if a lisp exectuable image
* is created.
#define READ_ONLY_SPACE_START (SpaceStart_TargetReadOnly)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment