>
> The current scsh heap size is now 2,500,000 words, or 10,000,000 bytes.
>
> In 0.3, it was 1,500,000 words, or 6,000,000 bytes.
>
> Here's my (totally wild) guess: some of that delta is new code,
> most of it is extra debugging tables.
>
> Clearly, the static heap linker will help a lot. I also suspect Sommerfeld
> is right -- the static linker could wring more read-only data out of
> the heap than it does now.
>
> mmap() tricks would pay off but we'd have to be careful to do it
> in a portable way, because it isn't standard, and we still want to
> be able to build on systems that don't have it.
Even worse, some have it but it doesn't work reliable.
NetBSD, for example (ever since and still) has a mmap() that cannot be
trusted when used over NFS. It looks up the right filesystem *meta*
information, but the *data* you get is maybe not what what the server
has, but something that is in the client's *memory* pages (not the
*buffer cache* pages).
A scsh image is likely to be used only by one machine, but confusion
can even occur when your NFS client machine is the only one that
accesses then file: when you do this from more than one program on
this host (maybe `cp` an image and then try to load it). Maybe bad
things happens even when unmapping and remapping the files, I don't
don't know. I could ask some other folks about it if you want.
How important is this once the image bytecodes are stored in the text
segment? They're not scanned anymore anyway. I think mmap is a
dangerous feature to play with. The biggest problem is to ensure that
future generations of maintainers of a software will still know what
should not be done with these files. This is, BTW, how NetBSD came to
a vi that can't be used over NFS :-)
Ups, sorry for the lost post...
Happy hacking
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de> - Fax +49 40 522 85 36
BSD User Group Hamburg, Germany - See http://{net,free}bsd.www.org
|