* Raymond Toy [2011-08-29 17:00] writes:
On Sat, Aug 27, 2011 at 2:01 PM, Helmut Eller <heller@common-lisp.net>wrote:
Is it necessary that we reserve such large areas at startup?
#define READ_ONLY_SPACE_SIZE (0x0ffff000) /* 256MB - 1 page */ #define STATIC_SPACE_SIZE (0x0ffff000) /* 256MB - 1 page */ #define BINDING_STACK_SIZE (0x07fff000) /* 128MB - 1 page */ #define CONTROL_STACK_SIZE (0x07fff000 - 8192) (about 128 MB)
Why are read-only and static space so large when a core file is less than 30MB? And why do we need such huge stacks?
Don't know why they're set to these sizes, but long ago, everything was much smaller, including a default heap of 64 MB or so (except on Linux which had more). I think Douglas set these defaults. I vaguely remember a few use cases where the (original) control stack size was too small.
Perhaps now would be a good time to add command-line options to allow the user to set the sizes of the spaces like the -dynamic-space-size option.
Command line options would be good.
Perhaps we can lower some of these. I suspect the binding and control stacks could be on the order of a few MB. I think the read-only space needs to be fairly large if you save some large images like mcclim or maxima. (Maxima's RO space is 42 MB.) Not sure about static space; maxima uses about 5 MB of static space.
Can't we read the sizes of static and read-only space out from the core file?
With such settings one needs at least 720MB to start. That's a problem unless overcommitting is enabled.
Does anyone really have less than 1 GB of memory/swap nowadays? For a long time my linux box had just 512 MB RAM + 1-2 GB of swap.
I think those cheap virtual servers often don't have much RAM. 2GB in my case, no swap configured (as IO performance is rather unpredictable on such systems). If there are some other applications running then there isn't much room left. Even if we have 4GB available it would still be desirable to make the normal heap as big as possible. If I understand things correctly, half of the heap space is reserved for the copying garbage collector, so we could have something like (4GB-720MB)/2 which is roughly 1.6GB heap that is effectively usable. If the 720MB factor gets smaller we get more heap for the user. (We should also have a mark&compact GC for the oldest generation, but that's another issue.) Helmut