On Thu, Jan 03, 2008 at 01:39:37PM -0800, Josh Elsasser wrote:
> 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?
> > 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
> > down?)
> 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.
Updated patch attached, I've cleaned some things up and added a
warning message if it looks like there might not be enough memory.
One small question I just remembered, what is the reason the makefiles
in src/runtime set LINKFLAGS instead of LDFLAGS? I had to set both in
src/runtime/Config.x86-openbsd so that tools-for-build/Makefile picks
up the right linker flag to allow the dlsym test to pass.
Any comments or suggestions for improvements?