Here's my understanding of how it works. Garbage collection is completed
before the Unix fork system call is made. At the moment of the fork, the
original server VM process and the new image saving VM process share the
exact same pages in the Unix OS - due to "Unix copy-on-write memory
management".
Immediately after the fork, the server VM process continues processing
requests. Meanwhile, the image saving VM process proceeds to save the
image. As each process continues execution, they will "dirty" their
memory pages. Each dirty page means that that page is no longer shared
between the two processes - leading to increased OS memory resources
being allocated to the two processes.
If the server VM process is very active, then a lot of dirty pages will
be created, before the image saving VM process can complete. So, running
the image saving process at a lower priority may actually be detrimental.
One thing that occurs to me now, is whether or not the garbage
collection is completed before the fork. If not, and it's done first
thing by the image saving process, then it will be as you describe - the
whole memory gets copied anyway.
--
Yanni
Lukas Renggli wrote:
David, is what is said about memory management really true? I thought
that saving the image triggered a garbage collect what forces to copy
the whole memory anyway.
Lukas
On 23 July 2010 14:00, David T. Lewis <[email protected]> wrote:
On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote:
But How I can do that without fork? I track changes in another process and
when I do update I save image in this process.
How I can initiate image saving from ui process?
I don't understand what you are saying.
The thing is that using #fork to save the image has no effect (other
than wrecking the image), because #snapshot:andQuit: is eventually
calling a primitive that locks the complete VM anyway.
If you want to fork while saving the image you need to use an OS-level
fork, not a Smalltalk-level fork. You can do this with OSProcess for
example (check the Seaside mailing-list archive).
"UnixProcess saveImageInBackgroundNicely"
Explained in the method comment:
UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag
"When Squeak is used as a server it is sometimes desirable to
periodically
save image snapshots. This method forks a headless Squeak to perform a
snapshot without impacting the server Squeak. Very little additional
memory
is required to do this because Unix copy-on-write memory management
allows
the two Squeak images to share object memory while the save is performed.
The saved image is given a time stamped name, and the image name of
the main server Squeak remains unchanged. If niceFlag is true, the
background OS process runs at lowered scheduling priority."
Dave
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
