Re: [9fans] plan 9 overcommits memory?

["David Leimbach" <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2552 bytes --]