On 2010-07-23, at 9:03 AM, Yanni Chiu wrote: > 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
Let me clarify a few things. First the Copy On Write only makes a copy of the original page if the page is going to be written to. Now *usually* 99% of the write activity is in young/new space which starts with zero bytes of memory after the Full GC is triggered. So as the saving task is writing out say the 0-100MB of memory, the running VM is busy allocating and writing to objects at 100+MB so there will be no effect on pages 0-100MB. Of course there are some updates into the 0-100MB area but that is rare as compared to write activity in new space. So if the process doing the write runs at a lower priority it shouldn't have an impact on the process running the VM. The danger is that a full GC should occur which would cause a compaction, but a server image should not be doing full GC more than a few times per hour.... Maybe never... -- =========================================================================== John M. McIntosh <[email protected]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
