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

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

Таки ваша правда... Но работать с динамикой гораздо удобнее, чем передавать в каждую функцию указатели на буфферы, да еще и следить везде за размером.
Потом это не просто буфферы, а там классы, программа будет пестреть reinterpret_cast, что вообще не красиво и склонно к образованию разных багов.
В принципе серьезно задумываюсь над стеком, разделить тяжелые потоки и легкие отдельно. надо написать хороший анализатор стека, чтобы indirect-высовы понимал(виртуальные классы), рекурсия - фиг с ней, редко где применяется. Сейчас я сделал анализатор стека, но он понимает все, кроме индирект call...

кому надо - могу дать.

При таком использовании может подойти аллокатор, который выделяет память последовательно из пула фиксированного размера и не освобождает её. Освобождается весь пул при выходе из функции. А пулы памяти можно выделять, например, с помощью bitmap allocator.

Да, вариант тоже неплох, обдумаем, спасибо

[jcxz]

Таки ваша правда... Но работать с динамикой гораздо удобнее, чем передавать в каждую функцию указатели на буфферы, да еще и следить везде за размером.
Потом это не просто буфферы, а там классы, программа будет пестреть reinterpret_cast, что вообще не красиво и склонно к образованию разных багов.

А зачем? Или вы про вызов конструкторов классов для буфера?
Но что мешает явно его вызвать:
char buf[N];
new (buf) ClassName(...);
ClassName *p = (ClassName *)buf;
...

[ReAl]

char buf[N];
new (buf) ClassName(...);
ClassName *p = (ClassName *)buf;

Ну так этот «С-шный каст» ничем не лучше reinterpret_cast<>

Впрочем, тут без кастов можно и нужно. Раз уж placement new используется, его надо и использовать правильно:

Код

char buf[ sizeof(ClassName) ];

ClassName *p = new (buf) ClassName(...);

p.s. ещё тут