Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Message-ID | <s85319-dhd.ln1@wilbur.25thandClement.com> (permalink) |
|---|---|
| From | William Ahern <william@wilbur.25thandClement.com> |
| Subject | Re: malloc |
| Newsgroups | comp.lang.c |
| References | (3 earlier) <07552704-67e6-4ec8-9180-1aede4471a6a@1g2000yqv.googlegroups.com> <ln62f5g3h8.fsf@nuthaus.mib.org> <189309be-7354-48eb-87e3-c2ccb34c1770@t2g2000yqk.googlegroups.com> <ln1uptfk3k.fsf@nuthaus.mib.org> <20120217152431.839@kylheku.com> |
| Date | 2012-02-17 15:42 -0800 |
In comp.lang.c Kaz Kylheku <kaz@kylheku.com> wrote: > ["Followup-To:" header set to comp.lang.c.] > On 2012-02-17, Keith Thompson <kst-u@mib.org> wrote: <snip> > > If you call malloc() and it overcommits, it won't crash the > > program until you access the allocated memory. (The rationale for > > overcommitting is that most programs don't actually use most of > > the memory the memory the allocate. I find that odd) > Odd or not, it is borne out empirically. Applications are physically > smaller than their virtual footprints. Supposedly, and years ago when application developers where chummy with the kernel folks. > It may be the case that C programs that malloc something usually use > the whole block. > > But overcommitting is not implemented at the level of malloc, but > at the level of a lower level allocator like mmap. > > If the system maps a large block to give you a smaller one, that large > block will not be all used immediately. No, but it's not like allocators are mmap'ing large fractions of available memory. The trend is toward more and smaller mmap'd backing blocks to, e.g., improve address randomization. > Another example is thread stacks. If you give each thread a one megabyte > stack and make 100 threads, that's 100 megs of virtual space. But that one > megabyte is a worst case that few, if any, of the threads will hit. Fortunately GCC already supports segmented stacks. Such support would have been there sooner were it not for overcommit reducing the apparent demand for such a feature. Although, glibc doesn't seem to be too eager to jump aboard. Perhaps they feel that a 5% performance hit is too high a cost to get rid of applications randomly crashing under high loads.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
malloc jgk@panix.com (Joe keane) - 2012-02-16 21:04 +0000
Re: malloc Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-16 13:21 -0800
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-16 16:16 -0700
Re: malloc Paavo Helde <myfirstname@osa.pri.ee> - 2012-02-17 14:46 -0600
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 14:51 -0800
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-17 19:58 -0700
Re: malloc Paavo Helde <myfirstname@osa.pri.ee> - 2012-02-18 02:18 -0600
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 01:58 -0700
Re: malloc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-18 15:30 +0000
Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-18 10:36 +0000
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 10:53 -0700
Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 16:43 -0800
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 20:03 -0700
Re: malloc Miles Bader <miles@gnu.org> - 2012-02-19 12:49 +0900
Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 21:08 -0800
Re: malloc "io_x" <a@b.c.invalid> - 2012-02-19 18:23 +0100
Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-18 21:06 -0800
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-18 23:06 -0700
Re: malloc "Asger Joergensen" <Junk@Asger-P.dk> - 2012-02-19 15:54 +0000
Re: malloc BGB <cr88192@hotmail.com> - 2012-02-19 09:37 -0700
Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-16 20:27 -0500
Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-16 23:40 -0800
Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-17 02:26 -0800
Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-17 04:01 -0800
Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-17 09:25 -0800
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 14:49 -0800
Re: malloc glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-02-18 01:43 +0000
Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-18 02:04 +0000
Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-18 03:04 +0000
Re: malloc Robert Wessel <robertwessel2@yahoo.com> - 2012-02-17 22:15 -0600
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-17 23:48 -0800
Re: malloc Kaz Kylheku <kaz@kylheku.com> - 2012-02-17 23:29 +0000
Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-17 15:42 -0800
Re: malloc "io_x" <a@b.c.invalid> - 2012-02-19 18:24 +0100
Re: malloc Kleuske <kleuske@nowhere.net> - 2012-02-19 20:41 +0000
Re: malloc James Kuyper <jameskuyper@verizon.net> - 2012-02-19 18:05 -0500
Re: malloc "io_x" <a@b.c.invalid> - 2012-02-20 12:24 +0100
Re: malloc Kleuske <kleuske@nowhere.net> - 2012-02-20 13:56 +0000
Re: malloc "io_x" <a@b.c.invalid> - 2012-02-20 15:14 +0100
Re: malloc William Ahern <william@wilbur.25thandClement.com> - 2012-02-19 15:19 -0800
Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-17 08:06 -0500
Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-18 07:57 -0800
Re: malloc Keith Thompson <kst-u@mib.org> - 2012-02-18 10:57 -0800
Re: malloc Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-19 08:51 -0500
Re: malloc Noob <root@127.0.0.1> - 2012-02-17 11:44 +0100
Re: malloc "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2012-02-17 17:05 +0100
Re: malloc pete <pfiland@mindspring.com> - 2012-02-17 11:19 -0500
Re: malloc Noob <root@127.0.0.1> - 2012-02-17 17:30 +0100
Re: malloc James Kuyper <jameskuyper@verizon.net> - 2012-02-17 11:31 -0500
Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-17 20:31 +0000
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-18 00:01 -0800
Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-18 17:07 +0000
Re: malloc Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-18 18:14 -0800
Re: malloc scott@slp53.sl.home (Scott Lurndal) - 2012-02-19 17:14 +0000
Re: malloc Goran <goran.pusic@gmail.com> - 2012-02-16 23:43 -0800
Re: malloc "io_x" <a@b.c.invalid> - 2012-02-19 16:44 +0100
csiph-web