buffer allocation/destruction

[Rob Landley]

Ah, top quoting.  The sign somebody's been dealing with traditional business 
types used to stapling their reply to the top of the previous document and 
throwing it in the "out" tray...

On Monday 29 August 2005 20:23, Jason Schoon wrote:
> Especially given that we provide a configuration option for allocating in
> either .bss, heap, or stack (although I'm not sure how well it has been
> followed),

Not very.  Going through and cleaning that up is in the current TODO.

> I would think we wouldn't want to start blindly allocating on 
> the stack. I have been on many embedded systems with 2k or smaller stacks.
> They are a pain all around, but it seems as though Busybox has at least
> made a partial attempt to address this.

At one time it did, but not so much recently.  The only testing we've gotten 
is on the linux kernel, and that doesn't have stacks that constrained.  (Not 
even the nommu variants.)

Shaun Jackman's newlib work is the closest we've come to running in a 
non-linux environment in the past few years.

> I agree the cleanup is a mess though. atexit() is a great idea for the most
> part, although as you said, it is not immediate reclaming of space. If
> somebody cares at all about this cleanup stuff, rather than just letting
> the memory be return automatically, they probably want it returned as soon
> as possible.
>
> Ugh. Memory limitations are a pain.

Memory limitations are what busybox is all about.  One of the things, anyway.  
But there are at least three different _types_ of memory limitations in play 
here.  Executable size, heap size, and stack size.  And a lot of the 
optimizations we can make are mutually exclusive.

What we've _been_ optimizing recently is executable size first (since flash 
and running from a CD are generally a lot more constrained than dram, and 
saving executable bytes saves the dram it would be loaded into as well), 
followed by saving heap space.

Allocating on stack means you save two function calls per allocation (the 
malloc() and the free()), plus memory never leaks, plus you don't have to 
worry about heap fragmentation, plus you don't need the data structures used 
to keep track of heap fragments (saves space _and_ time; malloc in a tight 
loop can slow you down quite a bit even without taking cache non-locality 
into consideration)...

It has a lot to recommend it.  And there are systems out there with 4k stacks 
where this just isn't an option, but do we run on those now, and are we 
interested in doing so?

Rob