Consider memory alloc API with explicit size param for m_free()

[pfalcon]

When dealing with interpreters, object size size is either implicitly known (for example, basic representation of object has fixed size, like 8 or 32 bytes), or size is stored explicitly on interpreter's level (for example, array size needs to be stored in object header anyway). This means that it may be possible to optimize low-level memory allocation system by not storing memory chunk size (thus saving memory), instead relying that higher levels will pass size explicitly.

Quick look at current sources doesn't show that MicroPython is ideally suited for such optimization, but that's why I write - to propose to add that as a (non-immediate) design goal.

First steps towards that can be simple: make m_free() have signature m_free(ptr, size), and m_realloc(ptr, old_size, new_size), then while going over code to adjust call sites, see if what to pass as "size" param is obvious. In case it's not, well, pass 0, and leave larger refactors to someone who really will implement alternative allocators. Ultimately, there're good reasons for having explicit size field for all variable-length objects, IMHO.

[dpgeorge]

Good idea.

In the current garbage collector (that runs properly only on the MCU), the object size is implicitly known. There is a bitmap at the very start of the heap which indicates which blocks (32 bytes each) are allocated. So an object size can be computed by working out how many blocks are contiguously allocated. There is also a bit to indicate "start of run of blocks".

[dpgeorge]

Okay, I've implemented it as you suggested, with an explicit size parameter for m_free and m_realloc. The macros you should use are m_del, m_del_obj and m_renew.