> I don't know what VisualWorks is doing WRT sharing perm space, but for
> what it's worth Squeak can be amazingly fast at starting images in
> some circumstances. Try "UnixProcess forkHeadlessSqueakAndDo: [something]"
> to see how quick it is. This is platform dependent and hence not in
> line with Squeak goals (also requires OSProcess from SqueakMap), but
> it shows what is possible.
> 
> This shares all of the object memory initially, and as time goes on
> the two object memories start using their own memory. It does not
>

Is that because Linux shares pages somehow and does copy-on-write or
something? Just curious.
--

Exactly. All of the Squeak object memory is data space that is
shared when the fork() occurs. Unix memory management makes sure
that additional memory pages are allocated only when one of the
Squeaks updates something in the object memory.

> I read your "save-image-in-another-process-trick"-posting (possibly on
> the seaside list, don't remember) and it is quite neat. :)

Yes, this does the same thing. The child Squeak just writes the image
and changes files, which does not involve much change to its object
memory.  As long as the parent Squeak is not too active, very little
addition real system memory is required to do this. The fork() is very
fast, there is no image startup overhead, and the net result is a quick
way to do a big image save in background without stopping the parent
Squeak (the one running the Seaside server, for example).

Dave





> How quickly do the object memories diverge?  Would a full garbage
> collect screw this up, or is old space pretty stable?  I posted
> recently on the Seaside list thinking about a model where we forked a
> Squeak image for each session, but with the qualifier "once we have
> some nice small images".  But maybe that's not necessary?

Well, you would have to try it to see what happens, but my expectation
is that a full GC would stir up the object memory completely, so you
would end up with the two Squeaks that use about twice as much memory
as one Squeak. If you just run an xosview monitor (or something
similar), you can get a good feel for the memory and cpu impact.

You will get very fast image startups using the fork() approach, plus
the illusion that everything is occuring with Squeak (you don't have
to go out to the operating system to start up another Squeak). But
you would still want to use small images if you expect all of the
Squeaks to be fairly active. 

Side note if you want to experiment with this: When you fork a new
Squeak, both Squeaks are sharing many of the same external resources
(everything except the socket connection to the X display).  This
includes image and changes files, stdin/out/err, and any files that
might be open for some reason. Sharing the same changes file seems
to cause no problems for short periods of activity, but be sure to
do something about this if you are going to run multiple Squeaks
that do a lot of separate things (the save image in background
goodie handles this, because it saves to a new file name).

Dave