release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Wiki > Main > BuflibMemoryManagement (compare)

Difference: BuflibMemoryManagement (r6 vs. r5)

This project is part of the Google Summer of Code 2011 project.

Project nameStudentMentorBackup mentor
Port buflib from the pluginlib over to the core Thomas Martitz (kugel)Frank Gevaerts (gevaerts) ???

Description

Rockbox has no malloc() in the core. Therefore we have always worked with static buffers or buffers which cannot be freed, resized or allocated after audio playback started, leading to somewhat annoying "Please reboot to enable" messages. Since Rockbox runs on a wide range of players with vastly different properties, it has become increasingly difficult for us to chose the right size for buffers. malloc() is not an option for various reasons. One of the main reasons is memory fragmentation, since many targets have no MMU to resolve this problem. However, the plugin library has a promising allocator - buflib - hich is handle based and can free and compact, move or resize memory on demand. My project will integrate buflib into the core as the main allocator for dynamic memory allocation needs. This will get us rid of one of the biggest limitations we have to date, enabling us to implement more awesome features without sacrifying too much valuable memory and without the need to reboot to activate them. The key feature of buflib is indeed compaction. It means it can move allocations to fill holes caused by freeing memory, which solves the fragmentation issue.

Project Plan

  • Ensure correctness of buflib DONE
  • Remove all direct audiobuf access, and replace them with buffer_alloc or other allocation mechanisms if needed DONE
  • Replace all buffer_alloc() with buflib_alloc(). DONE
  • - buflib has now exclusive control over allocations in the main memory (buffering gets the audio buffer via a buflib_alloc() call) DONE
  • Refine the scheme for introducing and handling compection DONE
  • Extend buflib according to that scheme DONE
  • Work on enabling compaction and fixing any regression it may introduce DONE (there still may be unseen regressions left of course)
  • - Rockbox has now a compacting dynamic memory allocator DONE
  • Optimized compaction mechanism to be less user-visible

Currently working on

Achievements

  • Replacing buffer_alloc() and buffer_get_buffer() calls with appropriate buflib ones.
  • Worked into the buflib code. Added small bits for debugging purposes (e.g. named allocs)
  • Analyzed all current buffer_alloc() and direct audiobuf[] users/accesses, audiobuf accesses are all resolved and refactored into API calls (buffer_get_buffer()).
  • Designed and Implemented an API for the core to use buflib, which should already now work well with compaction
  • Added lots of test cases for buflib
  • Added buflib to the core, replacing buffer_alloc()/buffer_get_buffer()
  • Enabled compaction, with in-rockbox little test scenario (in the debug buflib allocations screen)
  • Made LastFM? logging runtime switchable without requiring reboot

Code

Some of my code and progress can be found at http://github.com/kugel-/buflib (my out-of-tree buflib work) and http://repo.or.cz/w/kugel-rb.git (the gsoc2- prefixed branches) I will post to Flyspray once I consider something for SVN.

  • FS#12133 - Dircache patches: Reworks dircache with some patches, many of them are in respect to buflib conversion.
  • FS#12159 - GSoC?/Buflib: Remove direct audiobuf accesses: Replaces direct audiobuf accesses with buffer_get_buffer, buffer_release_buffer() and buffer_available() APIs
  • FS#12186 - GSoC?/Buflib: Put extended buflib into core (2 Patches, The mere buflib insertion patch and the compaction enablement patch)

-- ThomasMartitz - 19 May 2011

r6 - 12 Aug 2011 - 13:18:17 - ThomasMartitz

Revision r6 - 12 Aug 2011 - 13:18 - ThomasMartitz
Revision r5 - 10 Jul 2011 - 00:04 - ThomasMartitz
Copyright by the contributing authors.