Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #14216
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Newsgroups | comp.lang.c, comp.lang.c++ |
| Subject | Re: malloc |
| Date | 2012-02-18 02:04 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <20120217175652.409@kylheku.com> (permalink) |
| References | (4 earlier) <ln62f5g3h8.fsf@nuthaus.mib.org> <189309be-7354-48eb-87e3-c2ccb34c1770@t2g2000yqk.googlegroups.com> <ln1uptfk3k.fsf@nuthaus.mib.org> <af88e224-88be-4dd3-b702-7e8ea50b70b9@n8g2000pbc.googlegroups.com> <jhmvnm$f7n$1@speranza.aioe.org> |
Cross-posted to 2 groups.
On 2012-02-18, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > In comp.lang.c++ Joshua Maurice <joshuamaurice@gmail.com> wrote: > > (snip) > >> Really? The explanation that I'm most familiar with is that most fork >> calls are immediately followed by exec, and thus if you're low on >> memory, then a large process cannot spawn a new process without >> overcommit because the only process create primitive is fork, which >> "copies" the memory space of the parent process. > > That was fixed about 20 years ago. Among others, there is vfork() > > "vfork - spawn new process in a virtual memory efficient way" > > A simple explanation is that vfork() tells the system that you > expect to call exec() next, and it can optimize for that case. vfork is a dangerous hack which exposes the semantics of the optimization of fork to the program. A modern copy-on-write fork hides the semantics: the parent and child spaces are shared, but appear duplicated. A copy-on-write fork does have to account for the virtual space required to duplicate the private mappings of the parent process, because those will be copied physically if they are touched. If you have a 500 megabyte process, of which 400 megabytes are private mappings, and that process forks, the virtual layout of the system increases by 400 megabytes. If overcommit is not allowed, that means that the 400 megabytes has to be counted as physical memory. Joshua is completely right here: forking is one of the use cases for overcommit for this reason.
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 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 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-17 09:37 -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 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 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