Subject: Re: [linux-audio-dev] replacing malloc
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue May 23 2000 - 14:39:09 EEST
>>And why the hell does LADSPA need those 99999 different delay and fbdelay
>>plugins??? I'm sure its because of "malloc()" is broken wrt RT. But, hey,
>>this can be fixed in other ways! Cant you just tell the plugin at
>>activation time what the maximum delay should be?
>
>RT audio engine could lock up memory in larger pieces and each plug-in
>should request memory from there via our own malloc-replacement. If audio
>engine runs short of memory, a new big memory block could be malloced
>and locked up -- that can be done on-the-fly as far as I can tell.
>
>For non-RT systems the mallocs could be enough.
>So, should we recommend to use ladspa_malloc() instead of malloc()?
You must be very, very careful about replacing malloc. It represents
literally hundreds of man-years of accumulated wisdom about dynamic
memory allocation. There are implementations like libhoard, for
example, that not only contain the usual malloc wisdom, but also do an
incredible job at dealing with multithread issues.
The only significant problem with malloc in an RT system is that it
may call brk/sbrk(2). If you're going to replace malloc to make it
RT-usable, this is the key thing to avoid. Its also true that malloc
is not always deterministic, but by several orders of magnitude the
primary source of this non-determinism is from the brk(2) call, not
malloc's own internal operations.
For years and years, people have griped and complained about malloc as
a bottleneck. There are a few situations where it is clearly
suboptimal, the most obvious being large numbers of allocations and
releases of same size chunks of memory. The result of all those
complaints is that for almost anything else, its hard to beat, bar the
brk/sbrk(2) issue.
--p
This archive was generated by hypermail 2b28 : Tue May 23 2000 - 15:11:56 EEST