[vorbis-dev] alloca() problem with CodeWarrior

[Brian Hook]

At 01:12 AM 3/15/2002 -0500, Monty wrote:
>The common denominator in this case would degrade performance and
>significantly increase memory usage due to heap fragmentation.
>Installing the bloody compiler patches (or finding a working alloca())
>is the correct solution.

Well, one alternative which involves work is to use alloca() on systems 
where it's available and stable, and provide a heap based fall-back through 
#defines:

#ifdef ALLOCA_AVAILABLE
#define OV_ALLOCA(x) alloca(x)
#define OV_UNALLOCA(p)
#else
#define OV_ALLOCA(x) ov_alloca(x)
#define OV_UNALLOCA(x) ov_unalloca(x)
#endif

//Thread safe pool based memory manager
//that returns a pointer to a statically allocated
//global heap.
extern void *ov_alloca( int bytes );
extern void ov_unalloca( void *p );

The ov_alloca() implementation could be done fairly trivially using a fixed 
memory pool with trivial block compaction and merge.  It wouldn't have to 
be that robust since you know exactly how/when it's called.  The only 
really important thing is to make sure that it's reentrant and thread safe 
somehow (actually, come to think of, how is ov about thread safety?)

You could make the faux alloca stack a fairly large size (user definable, 
of course) and it wouldn't cause too many problems on most systems unless 
it was actually being used and thus paged in.

Of course, I'm sure someone else has thought of this =)

Brian

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.