Аллокатор для 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 еще хуже.

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

[Forger]

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

Я в свое время заморачивался, даже делал дефрагментатор, но это оказалось ненадежным, потому как в таких системах сложно добится детерменирванного времени захвата/высвобождения куска памяти.
По сему я остановился на варианте т.н. pool памяти, но таких пулов не один, а несколько - каждый имеел различный размер кусочков (slice).
Так же был диспетчер всех этих пулов, который сам выбирал при захвате пул с наиболее подходящим размером кусочка.
Т.е. в каждом пуле кусочки равного размера в пределах самого пула, но у каждого пула свой размер кусочков.
Так же этот диспетчер собирал статистику в рабочем режиме, и пре перезапуске прошивки автоматически создавал пулы с размерами кусочков и их числом на основании статистики последнего сеанса работы прошивки (статистика писалась в eeprom).
Пул-память дает четко детерменированное время захвата/освобождения кусочков.
Да и фрагментация как таковая тут полностью отсутствует.
Работало вполне эффективно.
Потом я это переписал на С++ с использованием smart pointer, стало еще удобнее работать - в коде нигде не было new/delete, куски сами освобождались, если на них уже никто не ссылался. Ориентировалось под применение RTOS, хотя можно и без нее.
А обычная куча со всеми ее недостатками, имхо, во встраиваемых приложениях - капризная и ненадежная вещь, уж лучше тогда взять проц с большим объемом памяти, чем кучу использовать. Я стараюсь избегать кучи в embedded проектах.
Ну как-то так

[SasaVitebsk]

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

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

Понятно, что раз такой вопрос становится, то принципиально может возникнуть ситуация, когда память не может быть выделена. Значит алгоритм работы должен предусматривать такой вариант. (У меня, например приостанавливалась подкачка, пока не разгрузится память)
А задачи, где динамическое выделение памяти целесообразно есть. Сейчас я одну такую решаю. На первом этапе буду работать с статическим распределением. Потом прикручу динамическое.