Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9885 - Add malloc library to codeclib

Attached to Project: Rockbox
Opened by MichaelGiacomelli (saratoga) - Monday, 09 February 2009, 07:13 GMT+2
Last edited by MichaelGiacomelli (saratoga) - Tuesday, 19 April 2011, 02:16 GMT+2
Task Type Patches
Category Codecs
Status Closed
Assigned To No-one
Player Type SW-codec
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

This patch adds a malloc implementation to the codec library (malloc, calloc, realloc, free) based on Daniel's dbestfit. Tremor is adapted to use it.

This patch decreases the worst case vorbis memory usage by at least 200KB by properly freeing temporary buffers. No other changes are made, and the old broken malloc implementation is left alone (speex still uses it for the moment).

While we have argued that malloc is not a good thing to have, removing it from tremor is probably not realistic, and the previous solution (tomal's attempts to use temporary mallocs) is unsatisfactory. Furthermore, once libfaad is fixed, this change will enable us to drastically shrink the codec buffer.
   vorbis_malloc_v1.patch (50.7 KiB) 
 apps/codecs/lib/SOURCES            |    5 
 apps/codecs/lib/bysize.c           |  449 +++++++++++++++++++++++
 apps/codecs/lib/bmalloc.c          |  394 ++++++++++++++++++++
 apps/codecs/lib/codeclib.h         |    7 
 apps/codecs/lib/bysize.h           |   25 +
 apps/codecs/lib/dmalloc.c          |  707 +++++++++++++++++++++++++++++++++++++
 apps/codecs/lib/bmalloc.h          |   27 +
 apps/codecs/libtremor/os_types.h   |   29 -
 apps/codecs/libtremor/oggmalloc.c  |   70 ---
 apps/codecs/libtremor/sharedbook.c |    4 
 10 files changed, 1631 insertions(+), 86 deletions(-)

This task depends upon

Closed by  MichaelGiacomelli (saratoga)
Tuesday, 19 April 2011, 02:16 GMT+2
Reason for closing:  Out of Date
Additional comments about closing:  Unneeded now that we have a malloc in the codec library.
Comment by Daniel Stenberg (bagder) - Tuesday, 10 February 2009, 14:40 GMT+2
I'm in favor of this, if it indeed means that we can narrow down the fixed amount of memory used.

We can then also offer access to this malloc system to plugins as well, to potentially make it easier for people to port stuff over to Rockbox.
Comment by Thomas Martitz (kugel.) - Tuesday, 10 February 2009, 17:58 GMT+2
Hopefully be able to run multiple plugins too? I tend to claim that most plugins hardly use the 512K buffer, there's probably space for more than one with some intelligent malloc'ing.

Just a thought though, nothing major.
Comment by MichaelGiacomelli (saratoga) - Monday, 02 March 2009, 04:38 GMT+2
bagder:

Is there some way to reinit the dmalloc library after a track change like the current rockbox malloc does? The current version does not do that, so if there is a memory leak, it will persist between tracks. I've tried setting to NULL the blockHead variable, but that doesn't seem to do it since attempting to pass the codecbuffer via add_pool() still crashes. I'll keep digging through the code, but I don't really understand a lot of it.

Edit: To be clear, I mean if I null blockHead and then try to readd the same pool of memory I still get a crash.
Comment by Daniel Stenberg (bagder) - Monday, 02 March 2009, 09:22 GMT+2
it's been a while since I worked on that code, but I'll give it a check and report back here soonish
Comment by Daniel Stenberg (bagder) - Monday, 02 March 2009, 23:59 GMT+2
Reinit as in forget everything and just restart?
Comment by MichaelGiacomelli (saratoga) - Tuesday, 03 March 2009, 00:02 GMT+2
Yes. I'd like to flush all state in dmalloc between track changes like the current malloc does in order to ensure that we don't get bugs or memory leaks that only occur under certain track orders.
Comment by Dan Everton (safetydan) - Saturday, 23 May 2009, 06:01 GMT+2
The LUA plugin that was recently committed uses Doug Lea's malloc implementation. You can see more information about it here http://g.oswego.edu/dl/html/malloc.html

How does it compare to this malloc?

Loading...