Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Codecs
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by MichaelGiacomelli - 2009-02-09
Last edited by MichaelGiacomelli - 2011-04-19

FS#9885 - Add malloc library to codeclib

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.

Closed by  MichaelGiacomelli
2011-04-19 00:16
Reason for closing:  Out of Date
Additional comments about closing:  

Unneeded now that we have a malloc in the codec library.

Admin
Daniel Stenberg commented on 2009-02-10 13:40

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.

Thomas Martitz commented on 2009-02-10 16:58

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.

MichaelGiacomelli commented on 2009-03-02 03:38

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.

Admin
Daniel Stenberg commented on 2009-03-02 08:22

it’s been a while since I worked on that code, but I’ll give it a check and report back here soonish

Admin
Daniel Stenberg commented on 2009-03-02 22:59

Reinit as in forget everything and just restart?

MichaelGiacomelli commented on 2009-03-02 23:02

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.

Dan Everton commented on 2009-05-23 04:01

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing