SBCL 进程的内存结构
2007-02-03 15:17:21| 分类:
Lisp
| 标签:
|举报
|字号大中小 订阅
最近由于成功地重新安装了 GNU/Hurd,开始考虑将 SBCL (Steel-Bank Common Lisp) 移植到 GNU/Hurd 的可能性。
将 Lisp 平台移植到新操作系统平台的一个关键的问题是进程的内存映射表结构,和那些完全从 C 编译出来的程序不同,Lisp
平台必须明确地知道所在操作系统中进程的内存布局,才能正确地分配动态内存空间以及垃圾收集。下面的代码片段取自 SBCL
源代码(src/compiler/x86/parms.lisp):
#!+linux
(progn
(def!constant read-only-space-start #x01000000)
(def!constant read-only-space-end #x037ff000)
(def!constant static-space-start #x05000000)
(def!constant static-space-end #x07fff000)
(def!constant dynamic-space-start #x09000000)
(def!constant dynamic-space-end #x29000000)
(def!constant linkage-table-space-start #x70000000)
(def!constant linkage-table-space-end #x7ffff000))
在 Linux 下通过 pmap 工具显示 SBCL 进程的内存空间使用情况也证实了上述代码所描述的内存分配结构:
01000000 4K rwx-- /usr/lib/sbcl/sbcl.core
01001000 40952K rwx-- [ anon ]
05000000 4K rwx-- /usr/lib/sbcl/sbcl.core
05001000 49144K rwx-- [ anon ]
08048000 132K r-x-- /usr/bin/sbcl
08069000 4K rwx-- /usr/bin/sbcl
0806a000 216K rwx-- [ anon ]
09000000 64K r-x-- /usr/lib/sbcl/sbcl.core
09010000 4K rwx-- /usr/lib/sbcl/sbcl.core
...
09546000 12800K r-x-- /usr/lib/sbcl/sbcl.core
0a1c6000 4K rwx-- /usr/lib/sbcl/sbcl.core
0a1c7000 328K r-x-- /usr/lib/sbcl/sbcl.core
0a219000 4K rwx-- /usr/lib/sbcl/sbcl.core
0a21a000 1584K r-x-- /usr/lib/sbcl/sbcl.core
0a3a6000 4K rwx-- /usr/lib/sbcl/sbcl.core
0a3a7000 224K r-x-- /usr/lib/sbcl/sbcl.core
0a3df000 4K rwx-- /usr/lib/sbcl/sbcl.core
0a3e0000 4404K r-x-- /usr/lib/sbcl/sbcl.core
0a82d000 499532K rwx-- [ anon ]
70000000 262140K rwx-- [ anon ]
(7ffff000 以后估计是 Linux 系统中进程的动态库表和其他部分了,应该不在 SBCL 管辖之内了)
b762b000 4K r-x-- [ anon ]
b762c000 4364K rwx-- [ anon ]
b7a6f000 1028K rwx-- [ anon ]
b7b70000 940K r-x-- /usr/lib/locale/locale-archive
b7c5b000 2048K r-x-- /usr/lib/locale/locale-archive
b7e5b000 4K rwx-- [ anon ]
b7e5c000 1192K r-x-- /lib/tls/i686/cmov/libc-2.3.6.so
b7f86000 20K r-x-- /lib/tls/i686/cmov/libc-2.3.6.so
b7f8b000 8K rwx-- /lib/tls/i686/cmov/libc-2.3.6.so
b7f8d000 12K rwx-- [ anon ]
b7f90000 140K r-x-- /lib/tls/i686/cmov/libm-2.3.6.so
b7fb3000 8K rwx-- /lib/tls/i686/cmov/libm-2.3.6.so
b7fb5000 4K rwx-- [ anon ]
b7fb6000 60K r-x-- /lib/tls/i686/cmov/libpthread-2.3.6.so
b7fc5000 8K rwx-- /lib/tls/i686/cmov/libpthread-2.3.6.so
b7fc7000 8K rwx-- [ anon ]
b7fc9000 8K r-x-- /lib/tls/i686/cmov/libdl-2.3.6.so
b7fcb000 8K rwx-- /lib/tls/i686/cmov/libdl-2.3.6.so
b7fdf000 28K rwx-- [ anon ]
b7fe6000 4K rwx-- [ anon ]
b7fe7000 4K ----- [ anon ]
b7fe8000 8K rwx-- [ anon ]
b7fea000 4K r-x-- [ anon ]
b7feb000 84K r-x-- /lib/ld-2.3.6.so
b8000000 8K rwx-- /lib/ld-2.3.6.so
bffeb000 84K rwx-- [ stack ]
既然一个 SBCL 进程的动态内存空间在虚地址范围上是固定的,那么显然有有限的:
(- dynamic-space-end dynamic-space-start) => #x20000000 => 536870912 => 512MB
也就是说 32 位系统下 SBCL 不可能同时分配超过 512MB 的动态内存数据,对于某些情形来说这是个严重的资源限制。这也就是为什么我们要用 64 位操作系统的原因。
评论这张
转发至微博
转发至微博
评论