On Fri, Apr 15, 2005 at 08:49:53AM +0200, goran.krampe at bluefish.se wrote:
> "David T. Lewis" <lewis at mail.msen.com> wrote:
> > 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