Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #17547

Re: malloc

From Kaz Kylheku <kaz@kylheku.com>
Newsgroups comp.lang.c, comp.lang.c++
Subject Re: malloc
Followup-To comp.lang.c
Date 2012-02-17 23:29 +0000
Organization Aioe.org NNTP Server
Message-ID <20120217152431.839@kylheku.com> (permalink)
References (2 earlier) <jhkaen$gvt$1@dont-email.me> <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>

Cross-posted to 2 groups.

Followups directed to: comp.lang.c

Show all headers | View raw


["Followup-To:" header set to comp.lang.c.]
On 2012-02-17, Keith Thompson <kst-u@mib.org> wrote:
> Goran <goran.pusic@gmail.com> writes:
>> On Feb 17, 11:26 am, Keith Thompson <ks...@mib.org> wrote:
> [...]
>>> I suspect he's referring to the malloc() implementation
>>> on typical Linux systems, which overcommits memory by default.
>>> It can allocate a large chunk of address space for which no actual
>>> memory is available.  The memory isn't actually allocated until
>>> the process attempts to access it.  If there isn't enough memory
>>> available for the allocation, the "OOM killer" kills some process
>>> (not necessarily the one that did the allocation).
>>
>> That crossed my mind, but what he said doesn't correspond with what
>> happens: malloc does return something and __doesn't__ crash the
>> program. OOM killer kills the code upon an attempt to access that
>> memory.
>
> 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.

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.

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.

Programs with lots of threads on GNU/Linux have inflated virtual footprints
due to the generous default stack size.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


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