Аллокатор для 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]

Касты с char не прокатят, char buf[ sizeof(ClassName) ]; тоже по ходу не прокатит, выравнивание должно быть до 4(а то и до 8) байт.
Ну эт такое, можно хоть long long buf[ (sizeof(ClassName)+7)/8]; втулить.

p.s. ещё тут

кроме placement new ничего дельного не увидел там, 10 страниц гвн
Только смысл в placement new есть только,если нужно делать отложенную инициализацию, чтобы код не пестрел всякими init()`ами.

Что значит ненадёжная? Чем она более ненадёжная, чем любой другой элемент программирования.

+1, вполне надежно работает. Конечно, приколы с нехваткой памяти(что может случится теоретически) разруливать сложно, и я склоняюсь к большому стеку для каждого треда + небольшая реорганизация тредов с целью уемньшения количетва тяжелых по стеку тредов до пары штук... Но для этого надо лопатить анализатор стека...

Я делал. Только дефрагментацию делал в защищённой секции. Причём не всю дефрагментацию, а лишь её завершающую стадию. Всё работало устойчиво.

Ну делать дефрагментацию кучи без MMU - это гемор жуткий: сложные указатели, сложные алгоритмы, куча багов, куча тормозов, да еще и не всегда реализуемо, тк проц может хранить адрес некоторое время у себя внутри(на пример, инструкции ldm/stm, интерруптабельные, к стати) - как мы тогда ему скажем, что адрес изменился? А если есть MMU и страничная адрессация, то и дефраг. особо не нужен, имхо