Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

As we all know, BREW comes standard with MALLOC() and FREE(), and that is the standard mechanism for freeing memory.

However, there is also a SYSFREE() for CONVERTBMP() and a ISHELL_FreeResData() for resources loaded by ISHELL_LoadRes*. As far as I know, none of these freeing functions are interchangeable.

My first question is this: Do all of thse functions use the same heap memory space, or do CONVERTBMP() and LoadResData() use space separate from the usual heap?

Secondly (this was asked by someone else in a previous thread but it went unanswered), IHEAP_CheckAvail() according to the BREW 1.1 API Reference collapses any adjacent free blocks in the heap. Does it do this well in practice? If so, it would effectively nuke any fragmentation issues introduced by CONVERTBMP if everything it allocates goes on the same heap...

Hey Victor,
At one point I was running a test app that called CONVERTBMP on every display frame, and if necessary called SYSFREE. During the frame processing it would do some string allocation, but my debug log showed that the CONVERTBMP pointer was the same address each time.
IOW, it looked like it was allocating and deallocating the exact same block every time. I'm not sure why this is. It might have been getting it from a reserved section of memory.
But also, for debugging, I think I was calling IHEAP_CheckAvail every frame as well, so if that was compacting memory then that was screwing up the test.
You should be able contrive a test app that will give you the information that you're asking about.
--t

Hey Victor,
At one point I was running a test app that called CONVERTBMP on every display frame, and if necessary called SYSFREE. During the frame processing it would do some string allocation, but my debug log showed that the CONVERTBMP pointer was the same address each time.
IOW, it looked like it was allocating and deallocating the exact same block every time. I'm not sure why this is. It might have been getting it from a reserved section of memory.
But also, for debugging, I think I was calling IHEAP_CheckAvail every frame as well, so if that was compacting memory then that was screwing up the test.
You should be able contrive a test app that will give you the information that you're asking about.
--t

IHEAP_CheckAvail() does not necessarily collapse blocks. It will do so only if needed and only until a large enough free block is made available.
-Bryan

IHEAP_CheckAvail() does not necessarily collapse blocks. It will do so only if needed and only until a large enough free block is made available.
-Bryan