One way around the whole static problem would be to let the user provide the memory for the metadata themselves. That would also make it easier to use libmemory in a multitasking environment without the need for locks (but of course would require some API changes/additions).
I like this idea, but it does require API changes, probably significant enough that it does not really work in this way as a "malloc". We could make the stock malloc APIs work with a single freelist (probably still requiring a lock in this case), but could provide extended APIs that allow callers to allocate memory against a particular freelist. Then each thread can have its own freelist and memory allocation zone.
This has some beneficial properties:
no lock needed if each thread provides its own freelist
you can portion dynamic memory according to each thread's specific needs
you can see how dynamic memory is being used across threads without any real effort put into analytics development - unlike a single heap case
From #82:
I like this idea, but it does require API changes, probably significant enough that it does not really work in this way as a "malloc". We could make the stock malloc APIs work with a single freelist (probably still requiring a lock in this case), but could provide extended APIs that allow callers to allocate memory against a particular freelist. Then each thread can have its own freelist and memory allocation zone.
This has some beneficial properties: