On 4/13/07, James Y Knight <foom@...> wrote:
> Read-only and static spaces should be much much smaller. I've had them
> patched to 256K each for a long time. Perhaps they can be even smaller, or
> nonexistent. If that's done, they probably don't really need to be
> adjustable from the command-line.
Read-only and static spaces could probably be limited to ~1 page/each,
maybe a bit more for safety's sake. ROOM on x86-64 reports 1,696
bytes used for read-only space and 2,512 bytes used for static space.
Even with more clever assembly routines like ALLOCATE-CONS-TO-FOO,
read-only space is not going to ever grow very big.
(The above discussion assumes gencgc, of course. Read-only and static
spaces function much differently on cheneygc ports, whereas for
gencgc, they're treated as convenient places to stash assembly
routines and NIL.)
> As for linkage table, (speaking out of ignorance here, perhaps), I'm not
> sure why that can't simply be a normal code vector in the normal heap:
> surely SBCL must already need to be able to move code and patch callers
> during GC? Then it wouldn't need to be adjustable, and wouldn't need to have
> a maximum size.
I am ignorant of how the linkage table works, so I defer this to more