[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No mapping fault



moore@defmacro.cs.utah.edu (Timothy B. Moore) writes:
> When building my hppa compiler under sunOS, cmucl dies in compiling
> hppa-insts.lisp with: 
> 
> Compiling DEFINE-ARITH-LOGICAL SH3ADD: segv_handler: mmap: Not enough memory
> segv_handler: No mapping fault: 0x0bfd8008
> segv_handler: Recursive no mapping fault (stack overflow?)
> 93 sunset> /etc/pstat -s
> 5928k allocated + 896k reserved = 6824k used, 89168k available
> 
> What's the fix?
> 
> Tim

Was this ever delt with?  Given that this bug report came in 2 months
ago, I would hope you haven't been sitting around just waiting for us
to get our act together...

Anyway, the compiler turns off garbage collection while it is
compiling individual top-level forms.  So if you try to compile a
*huge* form, you can run out of paging space.

The reason we turn off garbage collection during a form is kinda a
long story.  The short answer is that it's much faster this way
because the garbage collector never has to copy compiler temporary
data structures.  But it's actually more complicated than that.  It
turns out that before we put this hack in the amount of memory
retained after each GC would grow without bound while compiling any
moderatly sized file.  We never did figure out why so much stuff was
being kept alive, but we assume it must due to uninitialized slots in
stack frames retaining old pointers.  Anyway, the problem went away
when we added the without-gcing hack, so we quit worring about it.

I guess a better way to deal with this would be to temporarly increase
*bytes-consed-between-gcs* to 8 meg or so.  Then if it really needed
to GC during one form, it would.  But normally it would only gc
between forms.

The only problem with this is that it would require rewriting most of
the GC control code, because *bytes-consed-between-gcs* in only looked
at the end of a GC in order to determine where to set the next
*gc-trigger*.  *Bytes-consed-between-gcs* would have to be changed to
a function with a setf method so that we could do arbitrary stuff when
it changes.  I guess that wouldn't be too hard.

What do you all think?

-William Lott
CMU Common Lisp Group