On Tue, Jan 01, 2008 at 10:57:34AM -0500, Richard M Kreuter wrote:
> Josh Elsasser <josh@...> wrote:
> > On Sat, Dec 22, 2007 at 05:45:00PM -0500, Richard M Kreuter wrote:
> > > Josh Elsasser writes:
> > > > The default resource limits are too low, the simplest solution is to
> > > > run sbcl as a user in the daemon or staff login class.
> > >
> > > Once upon a time I wrote something to compare the hard datasize to the
> > > amount that the current SBCL instance wants to use, and bail out with an
> > > explanation if the resource limit is too low...
> > I haven't been able to find a way to accurately predict how much
> > memory SBCL will actually need. Perhaps it would be better to print a
> > message about --dynamic-space-size if dynamic space allocation fails?
> It's been a while since I looked at this, but does the sum of the sizes
> of the spaces turn out to be too small? If so, printing a message when
> allocation fails might do for now.
On my system you need about 25M free after the three sizes are
accounted for to get to the REPL. Since it doesn't seem to be
feasible to predict exactly how much memory will be needed, how about
printing a warning if it looks like it might be close?
/* Display a (hopefully) helpful warning if it looks like we won't
* be able to allocate enough memory. In testing I found that a
* minimum of 25M in addition to the three space sizes was needed
* to start SBCL. Show a warning below 32M so as to leave a little
* breathing room.
getrlimit (RLIMIT_DATA, &rl);
if (dynamic_space_size + READ_ONLY_SPACE_SIZE + STATIC_SPACE_SIZE + (32*1024*1024) > rl.rlim_cur)
"RUNTIME WARNING: data size resource limit may be too low,\n"
" try decreasing the dynamic space size with --dynamic-space-size\n");
> However, if David Lichteblau's dynamic allocation work is integrated,
> the failing allocation won't necessarily occur during initialization,
> and it will probably frustrate people when a resource limit is reached
> mid-way through a long-running computation. So ISTM it would still be
> desirable to try to determine whether SBCL will run afoul of the
> resource limits during initialization, if we can.
I may be missing something, but I don't see how SBCL can predict how
much dynamic space will actually be needed at runtime. Perhaps if
mmap() fails with ENOMEM then an os-specific error message could be
shown which suggests how to make more memory available.
> (Just to wonder aloud: might it turn out to be useful to perform this or
> an analogous sanity check on platforms other than just on a couple of
> BSDs, since anybody might have a system with resource limits tuned
Makes sense to me. OpenBSD and NetBSD check resource limits when the
pages are first mapped, but I'd imagine that SBCL would fail badly on
other platforms once it actually used enough of the mapped pages to
exceed it's limit.