On Fri, Apr 15, 2005 at 12:52:38PM +0200, Avi Bryant wrote:
> On 4/15/05, David T. Lewis <lewis at mail.msen.com> wrote:
> > > 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.
> 
> 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