Re: [Sbcl-devel] Re: SBCL on AMD 64

[<hba...@ma...>]

On Mar 17, 2006, at 12:40 PM, Juho Snellman wrote:

> On Fri, Mar 17, 2006 at 03:41:19PM +0100, Nicolas Neuss wrote:
>>   mprotect: Cannot allocate memory
>>   munmap: Cannot allocate memory
>
> I've never seen this before. Looking at the kernel source, the only  
> way
> munmap could fail with ENOMEM is if the kernel either ran out of  
> memory or
> the process-wide limit for distinct mapped memory areas got  
> exceeded. The
> latter option sounds more probable, and is also one way in which  
> mprotect
> can return ENOMEM. I think the limit can be adjusted through the file
> /proc/sys/vm/max_map_count (but haven't tested this). Does  
> increasing the
> limit help?
>
> Some alternative approaches which might reduce the pressure on the  
> memory
> maps:
>
>  * Increase the SBCL garbage collector page size to for example 32K
>    (constant gencgc-page-size, defined in src/compiler/x86-64/ 
> parms.lisp)
>  * Set small_generation_limit in src/runtime/gencgc.c to  
> NUM_GENERATIONS
>  * Set enable_page_protection in src/runtime/gencgc.c to 0
>    (this will essentially make the garbage collector non-generational,
>    and support for it might've bitrotted, so this should be the last
>    resort)

Thanks! I was also struggling with SBCL (0.9.10) hanging on a AMD 64  
system during the process of creating a pretty large data structure.  
I was only getting the first part of the error message, i.e. it would  
hang after printing "mprotect: Cannot allocate memory". However, I  
increased gencgc-page-size to 32K as you suggested, re-compiled, and  
it has been running fine ever since.

-Hazen