From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Tue, 4 Sep 2007 08:47:54 +0000 From: "Douglas A. Gwyn" Message-ID: References: <20070902212734.DF2D31E8C26@holo.morphisms.net>, Subject: Re: [9fans] plan 9 overcommits memory? Topicbox-Message-UUID: b76dc67a-ead2-11e9-9d60-3106f5b1d025 >> 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.