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 <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================