Robert Haas wrote:
> >> In fact, it wouldn't be that hard to relax the "known at compile time"
> >> constraint either. ?We could just declare:
> >>
> >> char lotsa_zero_bytes[NUM_ZERO_BYTES_WE_NEED];
> >>
> >> ...and then peel off chunks.
> > Won't this just cause loads of additional pagefaults after fork() when those
> > pages are used the first time and then a second time when first written to (to
> > copy it)?
>
> Aren't we incurring those page faults anyway, for whatever memory
> palloc is handing out? The heap is no different from bss; we just
> move the pointer with sbrk().
Here is perhaps more detail than you wanted, but ...
Basically in a forked process, the text/program is fixed, and the
initialized data and stack are copy on write (COW). Allocating a big
block of zero memory in data is unitialized data, and the behavior there
differs depending on whether the parent process faulted in those pages.
If it did, then they are COW, but if it did not, odds are the OS just
gives them to you clean and not shared. The pages have to be empty
because if it gave you anything else it could be giving you data from
another process. For details, see
http://docs.hp.com/en/5965-4641/ch01s11.html, Faulting In a Page of
Stack or Uninitialized Data.
As far as sbrk(), those pages are zero-filled also, again for security
reasons. You have to clear malloc()'ed memory (or call calloc()) not
because the OS gave you dirty pages but because you might be using
memory that you previously freed. If you have never freed memory (and
the postmaster/parent has not either), I bet all malloc'ed memory would
be zero-filled.
Not sure that information moves us forward. If the postmaster cleared
the memory, we would have COW in the child and probably be even slower.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +