From: Juho S. <js...@ik...> - 2005-09-14 15:38:27
|
On Wed, Sep 14, 2005 at 02:53:34PM +0200, Gisle S=E6lensminde wrote: > I was just to send a very similar question to the list. Unlike the orig= nal=20 > poster, I was not runing out of memory at "runtime", but when dumping a= n=20 > image > with save-lisp-and-die, I was running out of static space, since I had > a really big hashtable. I can then follow your advice and recompile sbc= l > with a modified parms.lisp, but my question is: Alternatively you can specify :PURIFY NIL to SAVE-LISP-AND-DIE to dump everything in dynamic space (this'll become the default on GENCGC platforms in the near future). > - What is safe to modify. Obvouosly, the memory areas cannot overlap, b= ut=20 > which > restrictions are on these memory areas anyway. The loader shouldn't map anything into those areas before SBCL has a=20 chance to call mmap. Basically conflicting things could be: * The program segments * The brk heap=20 * The stack * Shared libraries Execute "cat /proc/pid/maps" for approximation of what's likely to be mapped by the system and where. Additionally on x86-64 the static (or read-only? can't remember) space must be located in the lowest 4GB. But the <4GB space is otherwise pretty empty, so fitting larger spaces in there should be no problem. > - Why are these memory areas at fixed location? My guess would be that = it has > something with typetags to do, or that it is needed by gc-algorithm. = Just > curious. Because the core files (which are mapped into those memory areas on startup) contain pointers. If the memory spaces moved, we'd either need position independent code or fix the pointers on every startup. --=20 Juho Snellman |