Аллокатор для Cortex-M3, лучшая стратегия выделения памаяти? Опции

[brag]

Как ни крути, а динамическая память всеравно рано или поздно становится необходимой...
Готовые реализации использовать не могу по многим причинам(необходимость иметь несколько арен, thread-safety итп).
Нужен аллокатор, который будет давать минимальную фрагментацию в реальных условиях,минимальный обьем служебной памяти, производительность не особо важна, тк размер арены от силы 32кб.

Реальные условия - одни блоки памяти живут практически forever, другие выделяются/освобождаются подобно стековым переменным - в начале/конце функции соответственно. Блоки разной длины, от 16 до 1024 байт, редко больше. Юзать стек для этого не канает, тк нужно резервировать большие стеки для каждого потока, а это память будет использована на 5-10% в 90% времени.
В основном такое поведение имеет место в GUI и всяких обменах сообщениями, где сами алгоритмы гораздо тяжелее, чем аллокатор.

Пока сделал классическую реализацию best-fit, из служебных полей только размер,бит free/used в начале и в конце блока для облегчения free() и слияния соседних пустых блоков, тобышь заголовок весит 8 байт. Работает все гуд, но хз как оно будет при длительной работе девайса(ну там месяц,2,3).
Курил всякие разные реализации, но там делается упор в основном на производительность, а про фрагментацию редко где упоминается.
По рандом-бенчмаркам best-fit типа рулит, но смущает его тенденция к накоплению кучи маленьких(малоюзабельных) блоков.
First-fit, даже на простых тестах в моих реальных условиях показал гораздо худшую фрагментацию, чем best-fit. next-fit еще хуже.

Если кто-то имел дело с использованием,разработкой аллокаторов - буду благодарен за любую информацию...

[brag]

Спасибо.

Дефрагментатор не годится, тк мы не можем менять физический адрес, mmu в cortex-m3 нету. При наличии mmu, страничной адрессации(виртуальной памяти) фрагментация практически не страшна..

С пулами идея интересная, особенно статистика
В принципе можно модифицировать best-fit так, чтобы он не разбивал блоки малого обьема, а оставлял как есть. По идее, тогда туда будут падать те же запросы. Хотя такое ограничение уже есть - свободный блок дожнен быть такой, чтобы туда влезли заголовки и хотябы одно слово памяти (сейчас это 12байт), можно просто этот предел увеличить.
Благо, риалтайм не нужно, GUI,сеть,.. вещи довольно не риалтайм да и ОС у меня тоже не рт. Вообще рт вещи привык делать без OС на отдельных камнях, но эт уже не та тема..

А обычная куча со всеми ее недостатками, имхо, во встраиваемых приложениях - капризная и ненадежная вещь, уж лучше тогда взять проц с большим объемом памяти, чем кучу использовать. Я стараюсь избегать кучи в embedded проектах.

Ну их больше как-бы нету 64кб практически потолок, если забить все статикой и стеками, то не хватит их, при чем процентов 80 будет реально пустовать. Тут только внешняя память решает, но это дорого. Был бы мегабайт - стека вполне хватило бы..
Согласен, кучи - зло, но динамическая память нужна

За smart pointer спасибо. подобную технику reference counter уже использую, но там aquire и forget кишит, ну да, delete нету
А про него можно по подробнее, как удалось избавится от слежения(new,delete,aquire,forget) за обьектом?

апд.

Сама куча будет использоватся исключительно для хранения в ней обьектов C++, тоесть функций malloc(),free() нету как таковых. не помешает выделение блоков фиксированной длины с каким-то шагом(возможно просто степень двойки) - по идее тоже должно уменьшить фрагментацию + ограничение на разбиение малых блоков либо вообще запрет использования блоков неподходящей длины(тоже с каким-то порогом) - в итоге появятся редкоиспользуемые блоки небольшой длины, но другие блоки будут использоватся активно. по идее в таком случаи фрагментация дорастет до какого-то предела и дальше перестанет расти