Modify NDK default heap

Hi Will,

SYS/BIOS supports some heap implementations. And ti.sysbios.heaps.HeapMem is the most generic heap implementation.
Please check cdoc of ti.sysbios.heaps.HeapMem and see how to configure .cfg file to support an additional heap in the system.

Also, you can create a heap dynamically, rather than statically. If you prefer dynamic heap creation, the following pseudo code would work:

===============

  #include <ti/sysbios/heaps/HeapMem.h>
  #include <xdc/runtime/Memory.h>

  HeapMem_Params prms;
  HeapMem_Handle handle;
  Ptr buf; 

HeapMem_Params_init(&prms);
prms.buf = (Ptr) g_buffer; //something global array
prms.size = sizeof(g_buffer);

handle = HeapMem_create(&prms, NULL);

buf = Memory_alloc(HeapMem_Handle_upCast(handle), SIZE, 64, NULL);

================

Best Regards,
Kawada 

Hi Kawada,

  I understand how to create different heaps and set a specific heap to default.  What I am trying to do is change the NDK heap from default to a specific one I created.  Is there a way to do that without rebuilding the libraries.  Also, I think the only heap I need to modify is the mmBulkAlloc since it is only used for sizes greater than 3k bytes.  Is that correct?

Will

Will,

Does Kawada really answer your question?? It's marked verified and I just can't believe the "verified" post really answers the original question as you clearly wrote: " I understand how to create different heaps and set a specific heap to default".

We have the same problem: our default heap is in L2SRAM but we have large enough heaps in DDR3 and MSMCSRAM. The problem is that TI guys don't really care and just use Memory_Alloc(NULL,...) in mem.c.

We have built several versions of NDK 2.21.x.y and 2.22.03.20, I should say, it's not a big deal actually. But we try to avoid patching NDK, BIOS etc. whenever possible. Furthermore I've observed that (don't ask why, I just don't know) rebuilt NDK has lower performance than the vanilla one.

We'll try to fix it in the following way: to import mem.c in our source tree (e.g. under /network/patch/ndk_2_22_03_20/), and fix the issue. I hope the symbols exported from our "custom" mem.c will override the symbols from the os.a* library in the same way the generated code "overrides" packet buffers defined in mem_data.c

Regards,

Dmitry

EDIT: We have HeapMemMP heaps in DDR3 and MSMCSRAM so we cannot use one of these as the default heap. And we really don't want to split memory into sections etc.

Dmitry,

  No he really didn't answer my question but what we found is that we had to modify and rebuild the os lib because of file mem.c.  The mmBulkAlloc function uses the default heap and there is no way to modify that.  You either have to use a different default heap of modify mmBulkAlloc to allocate to a new heap that you have created.  We are using NDK 2.22.3.20 and it seems to work well.

Will

Will, Dmitry,

Actually, I do care about the user experience in the NDK and I appreciate you pointing out the shortcomings that you are experiencing here! :)

Currently, what Kawada mentioned is correct.  The mmBulkAlloc function will just call Memory_alloc for the default heap.  If you wish to use a different heap, then you must either change the default heap for your app, or rebuild the library (as you've discovered).

But as you have pointed out, this does not cover the use case of needing to change the heap that the NDK allocates from while not messing with the default heap.

I've filed the following enhancement request to ensure that we look at handling this in the future:

SDOCM00104169 need configuration param to allow user to specify heap used in mmBulkAlloc

Steve

Dear Steve,

Please note that "configuration param" is not enough! As I've described, sometimes you really need to setup bulk heap in runtime (before starting NDK).

As of today we've implemented the idea described in my previous post. We imported mem.c in our source tree, added _mmBulkAllocHeap() (c.f. obsoleted _mmBulkAllocSeg()), and modified mmBulkAlloc/mmBulkFree accordingly. It works as expected if you ensure mem.obj is linked BEFORE the generated stuff (CCS Build->Link Order). Otherwise you'll have linker errors (not runtime bugs!)

Regards,

Dmitry