|
Rockbox mail archiveSubject: GSoc Project: Buflib Memory managementGSoc 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 template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |