From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60709040639u39e8ee90o42e71103aa1ce2ab@mail.gmail.com> Date: Tue, 4 Sep 2007 06:39:37 -0700 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] plan 9 overcommits memory? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16870_15655509.1188913177305" References: <20070902212734.DF2D31E8C26@holo.morphisms.net> Topicbox-Message-UUID: b771f754-ead2-11e9-9d60-3106f5b1d025 ------=_Part_16870_15655509.1188913177305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/4/07, Douglas A. Gwyn wrote: > > >> malloc just moves the brk, but the backing pages don't get > >> allocated until the pages are accessed (during memset). > > "erik quanstrom" wrote in message > news:d7c705e9c3355e723c8f69677bf2d851@quanstro.net... > > > i'm just suprised that plan 9 overcommits. this makes > > this code nonsensical from user space > > if((p = malloc(Size)) == 0) > > Indeed, when I discovered that Linux was overcommitting memory > in much the same way, which in my view is erroneous design, I > added an optional feature to my portable malloc implementation > that (on systems neeing it) would touch every allocated page > before reporting success. (During the touch loop a trap catcher > would set a flag that would be tested after the loop to determine > whether there had ben any faults.) malloc really shouldn't have > to do this, but if you're insisting on overcommitment in the OS > then the library malloc() needs to do it. Otherwise, applications > that try to be careful may still fail "randomly", which is intolerable. > Yep, I've seen code with totally erroneous use of realloc work perfectly on Linux for example, due to it's behavior. Then I built it on FreeBSD and it failed appropriately :-). The problem there, in my opinion, was not the OS's behavior, but the inexperience of the coder in question with realloc. The terrible side effect of all these garbage collected languages or ones that don't make you manage memory much is that programmers have this attitude that they aren't to blame when their code has flaws. Mac OS X has many options for testing malloc results as well. It can scribble on pages etc... I'm sure glibc has these options somewhere too. They're great testing tools. Dave ------=_Part_16870_15655509.1188913177305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 9/4/07, Douglas A. Gwyn <DAGwyn@null.net> wrote:
>> malloc just moves the brk, but the backing pages don't get
>> allocated until the pages are accessed (during memset).

"erik quanstrom" <quanstro@quanstro.net > wrote in message
news:d7c705e9c3355e723c8f69677bf2d851@quanstro.net...

> i'm just suprised that plan 9 overcommits.  this makes
> this code nonsensical from user space
> if((p = malloc(Size)) == 0)

Indeed, when I discovered that Linux was overcommitting memory
in much the same way, which in my view is erroneous design, I
added an optional feature to my portable malloc implementation
that (on systems neeing it) would touch every allocated page
before reporting success.  (During the touch loop a trap catcher
would set a flag that would be tested after the loop to determine
whether there had ben any faults.)  malloc really shouldn't have
to do this, but if you're insisting on overcommitment in the OS
then the library malloc() needs to do it.  Otherwise, applications
that try to be careful may still fail "randomly", which is intolerable.

Yep, I've seen code with totally erroneous use of realloc work perfectly on Linux for example, due to it's behavior.  Then I built it on FreeBSD and it failed appropriately :-).

The problem there, in my opinion, was not the OS's behavior, but the inexperience of the coder in question with realloc.  The terrible side effect of all these garbage collected languages or ones that don't make you manage memory much is that programmers have this attitude that they aren't to blame when their code has flaws.

Mac OS X has many options for testing malloc results as well.  It can scribble on pages etc... I'm sure glibc has these options somewhere too.  They're great testing tools.

Dave


------=_Part_16870_15655509.1188913177305--