Re: [9fans] plan 9 overcommits memory?

[erik quanstrom <quanstro@quanstro.net>]

> Most applications probably use much less than 1 MB, but a lot depends
> on who wrote the program.  Our threaded programs typically have a 4K
> or 8K (K, not M) fixed-size stack per thread and that works fine,
> although you have to remember not to declare big arrays/structs as
> local variables.  malloc and free become good friends in threaded
> programs.

> As to guarantees that you won't run our of memory, they're almost
> impossible to give.  Programmer generally don't know how much memory
> their applications will use, so they can't reasonably preallocate.

that's a much stronger condition than "if there isn't backing memory,
brk fails".  perhaps that is difficult.  even if the actual condition
is estimated, wouldn't that be an improvement.

perhaps one could reserve, say 16MB total for stack space.  (or maybe
some percentage of physical memory.)  this could eliminate overcommits
for brk'ed memory.

> You see the same thing with real time.  Nobody knows how much time
> each task will consume beforehand.

> It would be cool to be able to get a handle on being able to shrink
> the memory occupied by an application dynamically.  Malloc (through
> brk()) grows the memory footprint, but free does not shrink it.
> The same is true for the stack.  Once allocated, it doesn't get freed
> until the process exits.

yes it would.  does plan 9 have programs that could make use of this
currently?

- erik