"Jay Carlson" <nop at nop.com> wrote:
> The macho C weenie in me is a little disturbed at the 8M of image that has
> to be allocated and read() in on each invocation.  It's not that I mind the
> 8M in the buffer cache; it's that every separate squeak process needs that
> 8M in the buffer cache and then at least another 8M of private unsharable
> malloc()'d heap memory that can never be reused across invocations.  OK, we
> can get that down to 800k with majorShrink, but a friendly dev/scripting
> environment that's not.


I agree.  Also, loading the 8M just has to be an important part of
Squeak's bootup time.  Smaller images should surely lead to faster
bootups.   I betchya a very good script running environment, without any
graphics in it, could be done in 1M-2M without much trouble.

And I'll propose a modification of your scheme: store Squeak "scripts"
as small image segments.  Have the minimal 2M image used for simply
executing scripts, and have a 6M image around that's used for editting
them.

I do like the idea of trying to get the image to load in the correct
place in memory, thus avoiding the need for a pointer-fixup pass. 
Actually, I'd guess it's common that images do come back in the exact
same place in memory, so long as you're working on a single machine. 
Sadly, this comment in #adjustAllOopsBy: suggests that a little more
work needs to be done, even in this nice case:

	"Note: Don't bypass this method even if bytesToShift is zero until the
RootBit problem has been fixed in the appropriate places."





-Lex