[Feature] Memory pool free interface need to add a handle

[RiceChen0]

Describe problem solved by the proposed feature

1. 目前内存池的申请接口是带句柄，释放接口是不带句柄的
2. 内容池的数据块要求没有block都要额外的增加4个字节，他的目的其实是为了在malloc的时候保存当前对象句柄。在free的时候，还原句柄，然后归还block。
3. 从上面的角度去看，每个block都浪费4个字节（浪费空间），free的时候还需要额外的还原句柄（浪费时间）

Describe your preferred solution

free接口增加句柄的好处

1. 节省每个block的额外的4个字节。
2. 明确了释放接口的内存对象句柄。
3. 释放空间能节省时间

Describe possible alternatives

No response

[BernardXiong]

这个在于这每4个字节是否浪费。

原来的考虑：

可以有不同的一些memheap，这些memheap在某些场合下是可以做heap的补充。上层在使用的时候只管用，也包括把多个memheap链接起来一起当普通heap使用，在释放的时候可以类似统一的free接口进行释放（不用再管具体是哪个memheap的事情）。

如果memheap_free时带handle句柄，需要解决memheap_as_heap的问题。

[RiceChen0]

熊大，你搞错了，我的issue是内存池不是内存堆

[BernardXiong]

熊大，你搞错了，我的issue是内存池不是内存堆

🆗 确实是有些

不过针对于memory pool，也同样是，需要评估4字节是否是浪费。直接free的好处也有，如果是在中断isr中free了，这个会挺好用，不需要知道pool object是哪个；另外这个前面的4字节相当于是一个链表头，在释放的时候串起来。

[RiceChen0]

熊大，你搞错了，我的issue是内存池不是内存堆

🆗 确实是有些

不过针对于memory pool，也同样是，需要评估4字节是否是浪费。直接free的好处也有，如果是在中断isr中free了，这个会挺好用，不需要知道pool object是哪个;另外这个前面的4字节相当于是一个链表头，在释放的时候串起来。

1. 针对链表头：其实这四个字节完全没有必要，因为内存块没有使用的时候，可以直接利用内存块的前4个字节。
2. 我认为RTT这样子做的目的是利用这四个字节在alloc的时候保存句柄，free的时候可以还原句柄。
3. 从上面的描述，RTT是面向对象的思想，free的时候却没了对象。
4. 如果在中断isr中使用，那么可以通过中断的arg传入，从这个角度，我们不应该考虑isr这个问题，而是针对本省的设计出发。

[jiuyueshenhua]

我上周看源码时也是这样想的。这有节省指针域的空间。而且free接口不对称。但是我后面改变想法了。

我觉得你的issue标题有误。看样子你其实是想重写内存池，把指针数据写到待分配的内存块里。然后把free接口替换了。
这样做的成本可能会大过做这件事的收益，到时候的反馈并不好。
但我赞同再补充额外传入内存池对象的free接口。

首先看浪费内存，浪费内存的标准是什么？就定个指针域占用内存最多是整个内存块的5%
那就是每个内存块至少要80个字节。内存块个数通常是多少，我不确定。那就取32个吧。总内存量要求就是2k。
看stm32常用芯片的存储大小，基本都能在8k以上。指针域占用内存的比率只会更小。

再看浪费时间，也就多了一个地址计算，估计也就省几纳秒。

在delete函数里，需要多回收4字节，但由于缓冲和局部性原理的优化，这点影响微乎其微。

最后看阻力，换接口后不仅是依赖此接口的内核代码需要修改。用户也需要修改旧工程。那么有几个用户会为了这几百个字节和几纳秒的时间去翻这旧工程呢？

所以重写内存池的做法会被不叫好。

再说代码的设计原则。free的时候直接归属到当时分配的内存池对象了。个人理解这里是有智能指针，所有权的味道。每个分配出的内存只能回到分配它的内存池对象，内存池对象拥有手下内存块的所有权。这里还是基于面向对象的。

但我认为有必要可以补充一个传递内存池对象的free接口。这样对用户来说操作内存池对象更灵活。也不会涉及isr调用需考虑内存池对象的问题。

[RiceChen0]

我上周看源码时也是这样想的。这有节省指针域的空间。而且free接口不对称。但是我后面改变想法了。

我觉得你的issue标题有误。看样子你其实是想重写内存池，把指针数据写到待分配的内存块里。然后把free接口替换了。 这样做的成本可能会大过做这件事的收益，到时候的反馈并不好。 但我赞同再补充额外传入内存池对象的free接口。

首先看浪费内存，浪费内存的标准是什么？就定个指针域占用内存最多是整个内存块的5% 那就是每个内存块至少要80个字节。内存块个数通常是多少，我不确定。那就取32个吧。总内存量要求就是2k。 看stm32常用芯片的存储大小，基本都能在8k以上。指针域占用内存的比率只会更小。

再看浪费时间，也就多了一个地址计算，估计也就省几纳秒。

在delete函数里，需要多回收4字节，但由于缓冲和局部性原理的优化，这点影响微乎其微。

最后看阻力，换接口后不仅是依赖此接口的内核代码需要修改。用户也需要修改旧工程。那么有几个用户会为了这几百个字节和几纳秒的时间去翻这旧工程呢？

所以重写内存池的做法会被不叫好。

再说代码的设计原则。free的时候直接归属到当时分配的内存池对象了。个人理解这里是有智能指针，所有权的味道。每个分配出的内存只能回到分配它的内存池对象，内存池对象拥有手下内存块的所有权。这里还是基于面向对象的。

但我认为有必要可以补充一个传递内存池对象的free接口。这样对用户来说操作内存池对象更灵活。也不会涉及isr调用需考虑内存池对象的问题。

1. free接口：
   1. 从接口兼容性角度来看，如果要考虑以前别人使用的，那确实不适合修改。但是从接口合理性角度来看，就是应该传递对象。
   2. 从4.xxx版本到5.xxx版本，我记得也是修改了内核的接口，也存在兼容性问题。用版本宏做了处理。
2. 内存问题：你不能按照整体内存来看待这个问题，你要看一个block的大小，这四个字节在整个block中比例。
3. 时间问题：他确实只是浪费很小的时间，但它就是浪费时间，节省这点时间，还可以提高实时性