注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Chun Tian (binghe)

超越自我,洞察宇宙

 
 
 

日志

 
 

SBCL 进程的内存结构  

2007-02-03 15:17:21|  分类: Lisp |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
最近由于成功地重新安装了 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 位操作系统的原因。


  评论这张
 
阅读(1410)| 评论(4)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017