> the problem is not really as easy as it might seem at first.
> malloc just moves the brk, but the backing pages don't get
> allocated until the pages are accessed (during memset).
>
i'm just suprised that plan 9 overcommits. this makes
this code nonsensical from user space
if((p = malloc(Size)) == 0)
/* malloc recovery code */
/* why bother? the kernel could be lying to us anyway. */
also, by default plan 9 assumes that there are 16 MB of memory
more than actually exist. i would think with today's large memories
typically, one would want to assume the worst and underestimate
the amount of memory required so malloc would fail rather than
getting a page fault later.
> you could argue for some kind of accounting that would
> ensure pages were available, but this could only be
> terribly pessimistic, especially in the case of stacks
> and fork.
how pessimistic would this be? i'll gladly trade a substantial
chunk of memory for failure on allocation rather than failure
on access.
- erik
