Allow more control over Pool sizes

[andy31415]

Problem

Existing code memory allocation story is not very uniform:

• separate pools exist for different purposes
• ChipMem defines access to 'heap' (which could be system heap or a locally allocated one)

Downside of these strategies:

• Large systems (e.g. Linux) do not need actual 'pools' of data and would rather use heap. We could always preallocate large amounts (e.g. saying a linux controller can connect to 100 devices at a time) and virtual memory will ensure we do not really use that much physical RAM, however this seems hackish

• Pools always need to be over-provisioned for the worst case, making each pool enerally waste a bit of RAM and this adds up the more memory poools we have

  Proposed Solution

  • Determine available pools and list them, to ensure we have a unified strategy for dealing with them. We are likely to need to figure out what to do with 'iterate over all allocated items' code logic. Is it required?
  • Allow existing pools a choice for a) use heap (will use this for large devices: android, iOS, linux, darwin). Eventually allow a 'max size' b) use a common pool of RAM/privateheap and have max size (rather than overallocating a bit for each pool, use RAM for data managment and allow memory sharing between different pools) c) Have centralized 'pool size' configurations for all our pools, to see at a glance configuration settings in our build system

[mrjerryjohns]

Additional recommendations:

1. BitMapObjectPool already exists as a templated type to implement pools. Should we just use that everywhere?
2. Bias towards application-owned object lifetimes if possible.
3. If that isn't possible, I'd highly recommend a model where the allocation algorithm when allocating out of a specific pool, degenerates to calling a 'AllocPoolObj' call that is provided by the application. This makes the code path regular and standard across constrained and unconstrained devices, with the latter actually returning a heap-allocated object as a result of that call.

[yufengwangca]

After auditing our code, we have three memory management implementations in current CHIP SDK.

1. Heap memory allocation APIs The interface is defined in support/CHIPMem.h, which provides standard C dynamic memory management like APIs, such as MemoryAlloc/MemoryCalloc/MemoryRealloc/MemoryFree.

   Its implementation is based on either the system C dynamic memory management or our private implementations in PrivateHeap.h/PrivateHeap.cpp.

2. Memory pool class BitMapObjectPool The interface is defined in support/Pool.h. This is actually not a typical pool implementation which provides similar APIs to allows dynamic memory allocation comparable to malloc or C++'s operator new based on pre-defined fixed blocks with different sizes. Such as you can not request a memory block from the pool with arbitrary size.

   It is a smarter C++ implementation of static array. You need to specify the list of object of the same type, and all of the memory managed by the pool is allocated only once (during construction of the pool object)

3. Memory pool class SystemObject This interface is defined in system/SystemObject.h, this pool implementation provides similar functions as BitMapObjectPool, but does not call the constructor as you add the element to the pool and destructor as you remove the element from the pool. It does not use operator New to initialize the new object added to the pool, so it does not have the meta overhead come with it.

In summary, the original Pool implementation based on pre-configured fixed-size blocks in support/CHIPMem-Simple.cpp has been replaced by private heap implementation in support/PrivateHeadp.cpp, and BitMapObjectPool is a C++ implementation of static array and SystemObject is a C implementation of static array.

[kpschoedel]

Don't forget System::ObjectPool