Heapless MP?

[WizardUli]

Is it possible to use MP without a global heap?

(I'm coming from embedded Rust ecosystem where such thing is normal and default having whole libraries heap-less working just with pre-allocated fixed-size-block pools where necessary for more dynamic behaviors or at worst having their own dedicated fixed sized "local" heaps where absolutely necessary e.g. for 3rd party BLE stacks etc..)

Since I'm expecting the answer to my question to be resounding NO I have some following questions:

• Is it possible to forbid new allocations in the global heap after some necessary initialization and use just stack from that time onward?
• Is it possible to have more heaps or use fixed-sized-block pools for some things that can't be just on stack?

[Josverl]

Is suggest reading https://docs.micropython.org/en/latest/reference/speed_python.html#ram-allocation

[projectgus]

Is it possible to use MP without a global heap?

Not really, unlike Rust the Python language doesn't have any concept of a reference to a variable on the stack. Some variable types like (small) integers and floats are allocated on the stack and passed by value[1], but everything else (strings, bytes, lists, dicts, slices[2] etc) is an object passed by reference and is allocated on the heap[3]. Similarly, importing a code module (even a pre-compiled one) may require one or more heap allocations.

Is it possible to forbid new allocations in the global heap after some necessary initialization and use just stack from that time onward?

There is an API for this - https://docs.micropython.org/en/latest/library/micropython.html#micropython.heap_lock . MicroPython also locks the heap in hard interrupt handlers and some other internal states where Python allocations are forbidden. However, you may find writing code to run with the heap permanently locked is very limiting.

You can track total memory allocated via the micropython.mem_info() functiion and gc.mem_alloc() functions, this might provide a good middle ground for ensuring you're not allocating too much while still being productive.

Is it possible to have more heaps or use fixed-sized-block pools for some things that can't be just on stack?

You can compile MicroPython with a custom Python heap size, so you can make a smaller heap and trigger a MemoryError earlier if you've used too much. However there's still only one Python heap.

Efficient MicroPython code minimises large heap allocations after startup (i.e. reusing any significant buffer objects, etc), however some small short-lived allocations are almost inevitable when using a language like Python. Generally this pattern doesn't become a problem (apart from the potential Garbage Collection pauses if you have tight timing constraints, and you can still temporarily disable GC via the standard gc.disable()andgc.enable() API or (better) manually trigger garbage collection at a convenient time.

I see @Josverl has linked to the docs about optimising memory usage. This is a good place to further understand "the MicroPython way" for memory management.

[1] q.v. copy semantics, Copy trait in Rust.
[2] There are some optimisations in MicroPython so short-lived slices don't require a heap allocation.
[3] Except for some immutable objects which are allocated in read-only flash space.

[WizardUli]

Thank you for the clear answers.
I had read the docs @Josverl linked before I started this discussion without finding there anything particularly useful to an overall question I should have probably begun with:

How to consider dealing with memory fragmentation in a GCed language without any memory de-fragmentation anything other than blind gambling? So far all I've found are techniques that may lower some originally unknown and possibly practically incalculable probability of enomem due to fragmentation to just another possibly practically incalculable probability.
(Same could be asked about any real-time aspects but I'm already aware there has been minimal publicly available research into time-bounded garbage collectors. Just disregard that for now.)

[projectgus]

How to consider dealing with memory fragmentation in a GCed language without any memory de-fragmentation anything other than blind gambling?

AFAIK if the runtime doesn't support automatically moving objects (which MicroPython can't as it has no way to update pointers to the moved object) then there is no provable way to avoid heap fragmentation in pathological worst case allocation patterns.

That said, in my experience (and that of many MP users) it's not that hard to avoid memory fragmentation issues in practice and have long-running stable MicroPython programs:

1. Make large allocations at startup and reuse those objects as needed.
2. If (1) is not possible then place an explicit gc.collect() before a significant re-allocation.

If (1) is followed then all other allocations will be small objects (1 or 2 heap blocks in size). Allocating small objects like this won't ever lead to fragmentation, provided those allocations aren't interleaved with larger ones.

This does make me wonder if we could add a micropython.heap_limit(max_alloc: int) function to set a ceiling on individual allocation sizes at runtime (i.e. after initial allocations, set this). But I'm not sure if it's a win for the programmer: setting it means you get a MemoryError back earlier, whereas if you didn't set it then you would probably never get a MemoryError back unless you chanced on a fragmenting allocation pattern.

[WizardUli]

If (1) is followed then all other allocations will be small objects (1 or 2 heap blocks in size). Allocating small objects like this won't ever lead to fragmentation, provided those allocations aren't interleaved with larger ones.

That's a good idea. It also reminds me of a solution to dynamic allocation I've seen here: https://www.drone-os.com/#heap where their heap consisted of static pools of various fixed-size blocks.
If one is willing to sacrifice some space and can estimate or even calculate the worst case usage of each of the pools then the result is not just no heap-fragmentation but also a time bounded allocation and de-allocation which may be a precursor to a time bounded GC.

[projectgus]

Interesting, IIUC then this is an embedded-friendly version of a slab allocator. We could conceivably do something like this in MicroPython, but it's harder for a dynamic language because we need a one-size-fits-all binary that's still small in code size.

may be a precursor to a time bounded GC.

I don't quite follow, in the case of MicroPython: If each pool may contain pointers to/from other pools then you still have to check every allocation in order to perform GC, don't you?

[bidrohini]

You can create your own fixed-size block pool by allocating a large bytearray at startup and then managing “allocations” and “frees” manually within this array.