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



Rockbox mail archive

Subject: GSoc Project: Buflib Memory management

GSoc Project: Buflib Memory management

From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Thu, 26 May 2011 08:55:20 +0200

Hello,

I know I'm a bit late, but now as the coding period started I wanted to
introduce my project. This is also the start of my weekly "Project
status" mails.

In my project, as described on [1], I will port the buflib from the
pluginlib to the core, enabling better dynamic memory mangement and more
knowledge about what we actually allocate.

What is buflib:
  - Buflib is a handle-oriented memory allocator. It is handle based
because it can do compaction[2] to reduce fragmentation. Compaction is
done at allocation time, and existing allocation therefore need to be
queried using the handle. Since other threads could do allocations as
well, you also need to query after yield(). Buflib is currently used in
pictureflow, to allocate memory for the images and album text caches.

It currently has a relatively simple API:
buflib_init(context, size);
buflib_alloc(context, size) - allocates 'size' memory and returns a handle
buflib_free(context, handle) - frees the memory indicated by 'handle'
buflib_get_data(context, handle) - gets the pointer to the memory
location indicated by 'handle'

Addtionally it has two functions to move all allocations around.
buflib_buffer_out(context, *size) - moves and resizes the buflib buffer
(and all it's allocations) up by 'size' bytes, returns the actual size
moved in 'size'. The freed memory will not be managed by buflib anymore.
buflib_buffer_in() - moves the buflib buffer down (and all allocations).

What will I do with buflib:
  - Buflib as such is not powerful enough for the core, at least not to
integrate it without making mm harder than it needs to be. Therefore I
will extend the API. In which way exactly is not yet clear, as I didn't
finish my analysis of how memory is used in the core, but I will most
probably add a "compaction callback" which would be called when
compaction happens and in which the buflib user can do the fixup instead
of constantly querying for the data pointer.
I will propose an API when I'm done with my analysis, which will
hopefully be done by the next weekend.
  - My current analysis has also shown that the core does some strange
things with memory, depending on it being non-movable. I will probably
re-write some of the strange uses to be more buflib-friendly.
  - I also want buflib to report us how we use memory, in the debug menu
or so, so that we exactly know where we use memory (and how much). This
is currently quite hidden.

  - The end goal is that all buffer_alloc() calls are replaced by
buflib_alloc(), and that there is no direct use of audiobuf[] anymore,
i.e. that buflib is the only means, besides buffering to alloc audio
data, to dynamically allocate memory (buffering would be also a buflib
user).

The project plan:
  - I'm currently in the analysis phase. After that I will replace
buffer_alloc() with buflib_alloc(), but without enabling compaction at
first. Enabling compaction is a separate step since I expect many tricky
problems there. After compaction is enabled I'm going to make actually
use of it by resolving some, if not all, the "Please reboot to
enable"-like allocations to do without reboot.

I really find this a fun project and I sincerely hope the outcome will
be of much use for Rockbox.

I feel I have forgotten something now, but I can't remember so I'd say
that's it for this week. As always, feel free to voice any comments.

Best regards.
Received on 2011-05-26


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa