Smalltalk scripting (was Re: jpython anyone?)
lex at cc.gatech.edu
Thu Dec 7 23:06:35 UTC 2000
"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
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."
More information about the Squeak-dev