2013/1/14 Mike Hommey <m...@glandium.org> > On Mon, Jan 14, 2013 at 11:28:19AM -0500, Benoit Jacob wrote: > > 2013/1/14 Mike Hommey <m...@glandium.org> > > > > > On Mon, Jan 14, 2013 at 11:09:07AM -0500, Benoit Jacob wrote: > > > > 2013/1/14 Mike Hommey <m...@glandium.org> > > > > > > > > > On Mon, Jan 14, 2013 at 11:43:44AM +1300, Robert O'Callahan wrote: > > > > > > I need a big read-only buffer full of zeroes. On Linux I could > mmap > > > > > > /dev/zero read-only, and something similar on Windows/Mac I'm > sure, > > > but > > > > > do > > > > > > we already have code for that, or better yet something like that > > > already > > > > > > mapped into memory? > > > > > > > > > > You could just use calloc(). Jemalloc will do the appropriate > thing. > > > > > > > > > > > > > Out of curiosity, how can it? Since the block returned by calloc is > not > > > > read-only, how would a subsequent non-zero write be handled? > > > > > > It doesn't set it as read-only, so that depends if roc really needs the > > > buffer to be read-only or not. > > > > > > > I tried to ask a different question: > > > > Roc wants (IIUC) to allocate dummy zero pages that don't actually consume > > memory. > > > > You propose (IIUC) that he use calloc() for that. > > > > My question, then, is: how could calloc() avoid actually allocating real > > memory pages? If calloc() could know that these pages won't be written > do, > > it could map dummy zero pages, but AFAICS it can't know that... > > It just maps anonymous memory (for big enough sizes), which is always > initially > zero pages. >
Right and I didn't understand how it could tell when it has to subsequently actually allocate memory when a write is made into these pages. Got my answer offline: it's a page fault. Benoit > > Mike > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
