Resources | developer.brewmp.com Resources | developer.brewmp.com

Developer

resources

Marking movable memory blocks

If an application must retain some amount of allocated memory while suspended or backgrounded, it is recommended that those blocks be marked as movable. When an allocated block is marked by the application as movable, it grants permission to the Brew MP heap manager to move that block to a new location in memory as needed. This means that if another application requests a larger block of memory than can be allocated, Brew MP may be able to move some allocated blocks to reduce fragmentation and satisfy the request.

By default, Brew MP locks memory blocks when they are allocated, which means they cannot be moved. To allow a block of memory to be moved, an application can use the UNLOCKMEM() macro. One of the parameters to UNLOCKMEM() is the address of the pointer to that block. Brew MP can change the location of the block and update the value of the pointer transparently to the application. However, if the application maintains more than one pointer to that block of memory, only one pointer will be updated. It is the responsibility of the application to make sure the new address is propagated to all pointers to that memory block.

Smart pointers may help in simplifying the management of pointers to movable memory blocks. In this approach, only a single reference to the actual memory block should ever exist, managed by the smart pointer.

Developers that wish to take advantage of this feature should be sure to read and understand the http://developer.brewmp.com/reference/api-all information for the LOCKMEM() and UNLOCKMEM() macros.

Applicability

Because of the restrictions involved in using movable memory and the effect of those restrictions on application performance, LOCKMEM() and UNLOCKMEM() should not be applied to every block of memory. Objects that are accessed multiple times per frame, for example, would not be good candidates. Instead, this approach should be applied to objects whose lifetime is necessarily long and that are accessed relatively infrequently. Data that must be retained while the application is suspended or backgrounded are good candidates.