Skip to content
Snippets Groups Projects
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
snapshot.
parent 2830e140
No related branches found
No related tags found
No related merge requests found
;; 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/build.sh -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.
#+linux
(setf (c::backend-foreign-linkage-space-start c::*target-backend*)
#x5f000000)
#+linux
(defconstant vm::target-foreign-linkage-space-start
(c:backend-foreign-linkage-space-start c::*target-backend*))
#+linux
(defconstant vm::target-dynamic-space-start
#x60000000)
...@@ -64,7 +64,7 @@ ...@@ -64,7 +64,7 @@
(setf (backend-page-size *target-backend*) 4096) (setf (backend-page-size *target-backend*) 4096)
(setf (c::backend-foreign-linkage-space-start *target-backend*) (setf (c::backend-foreign-linkage-space-start *target-backend*)
#+linux #x58000000 #+linux #x5f000000
#+solaris #x30000000 #+solaris #x30000000
#-(or linux solaris) #xB0000000 #-(or linux solaris) #xB0000000
(c::backend-foreign-linkage-entry-size *target-backend*) (c::backend-foreign-linkage-entry-size *target-backend*)
...@@ -235,7 +235,7 @@ ...@@ -235,7 +235,7 @@
#+FreeBSD #x28F00000 #+FreeBSD #x28F00000
#-FreeBSD #x28000000) #-FreeBSD #x28000000)
(defconstant target-dynamic-space-start (defconstant target-dynamic-space-start
#+linux #x58100000 #+linux #x60000000
#+solaris #x40000000 #+solaris #x40000000
#-(or linux solaris) #x48000000) #-(or linux solaris) #x48000000)
(defconstant target-foreign-linkage-space-start (defconstant target-foreign-linkage-space-start
......
...@@ -37,6 +37,24 @@ ...@@ -37,6 +37,24 @@
* However, Fedora 22 ther appears to be nothing mapped there. In * However, Fedora 22 ther appears to be nothing mapped there. In
* fact it appears to be free all the way to 0xf7c1b000. That would * fact it appears to be free all the way to 0xf7c1b000. That would
* allow a heap of size 2555 MB. * 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 libc.so
* 0xf7fb5000->0xf7fd9000 [anon]
* 0xf7fd9000->0xf7ffd000 ld.so
* 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) #define READ_ONLY_SPACE_START (SpaceStart_TargetReadOnly)
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment