>>>>> "nps" == Ng Pheng Siong <[EMAIL PROTECTED]> writes:
nps> Anyhow, on one such provider's test boxen, CMUCL (18d, from nps> Ports) segfaults upon startup. It is likely due to CMUCL nps> allocating gobs of memory at startup. I don't know anything specific about FreeBSD virtual servers, but can try to give some general information that may help. I know that CMUCL does work under User-Mode-Linux, which sounds like the equivalent of FreeBSD virtual servers. Try using a tool like strace to see what CMUCL is doing when it segfaults. This sort of problem is likely due to a difference in the memory zones that are available to the application in the virtual server. CMUCL needs to map various spaces (read-only space, static space, dynamic space, space for linking foreign code) at specific addresses, and will fail if the OS refuses to map at the address that it requested. The only solution to this problem is to find out which memory zones are available to applications and to rebuild CMUCL in consequence (with changes to the file src/lisp/x86-validate.h). CMUCL doesn't _really_ allocate huge amounts of memory at startup: it is only reserving a large amount of memory for possible future use. So its "virtual size" is very large, but only around 17MB are resident initially. You can reduce the virtual size by using the -dynamic-space-size commandline option (try with 100 for example), and by building a "small" core. nps> Looking around the archives, there is a "-lazy" command line nps> switch meant to work around Linux VM weaknesses. this is only present in CMUCL for Debian/Linux (and I don't think that it works any longer); it won't be useful for FreeBSD. -- Eric Marsden <URL:http://www.laas.fr/~emarsden/>
