Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
I have a need to be able to adjust the size of the dynamic heap at
launch time to free up memory for other uses. This is because I need
the heap to be large while compiling, and then smaller when running
(after dumping core and reloading), so that a large amount of data
can be loaded into C libraries in the same address space. This little
patch fills that need. I could be convinced it'd be to use a command-
line option than an env var if it's otherwise agreeable.
From: Juho Snellman <jsnell@ik...> - 2006-01-18 04:34:11
On Fri, Jan 13, 2006 at 03:02:07PM -0500, James Y Knight wrote:
> I have a need to be able to adjust the size of the dynamic heap at
> launch time to free up memory for other uses. This is because I need
> the heap to be large while compiling, and then smaller when running
> (after dumping core and reloading), so that a large amount of data
> can be loaded into C libraries in the same address space. This little
> patch fills that need.
This approach seems to be filling a somewhat uncomfortable niche
between a cmucl-style -dynamic-space-size option and Peter Van Eynde's
lazy allocation patch from a while ago.
If the goal is just to allow shrinking the maximimum dynamic space
size, just switching DYNAMIC_SPACE_SIZE and NUM_PAGES to variables
whose value is determined at startup would seem to make for a simpler
implementation (or am I missing something?). It'd also be nicer in
that only the neccessary amount of heap is mmaped at startup instead
of mapping the full amount and releasing the unneeded parts in
gencgc_drop_pages. This would be needed to account for what I suspect
is a more common need for an adjustable dynamic space size, people
wanting to run SBCL in environments with memory overcommit disabled or
other sorts of resource limits.
> I could be convinced it'd be to use a command-
> line option than an env var if it's otherwise agreeable.
If something like this goes in, I'd prefer a command-line option.
> However, the second requires the
> first, and the first may require the ability to relocate objects
> while loading a core (e.g. if the holes in your heap move between
> saving a core and loading it), which sounds somewhat difficult.
I belive Alastair has been thinking about making the dynamic space
relocatable. Then again, with a relocatable core having holes becomes
less important anyway.