Быстрый мультизадачный менеджер памяти

[slavav]

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

[bondkim137]

sup в сообщении #1074084 писал(а):

Если кто-то грязными сапогами небрежно прогуляется по своему куску памяти - то конец этой информации.

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

sup в сообщении #1074084 писал(а):

А вот что делать с выравниванием. Если это просто байтовые строки - то ладно. А если это память под структуры с содержательными объектами, то тут все не очень просто.

Тут хинты для менеджера памяти неплохо работают - по умолчанию все выравнивается, а для строк - нет.

sup в сообщении #1074084 писал(а):

Можно ли избежать полной блокировки бадди-аллокатора при выделении или освобождении памяти?

Вероятно можно - если на каком-нить из верхних этажей распихать локи. Главное, суметь разбить операцию выделения/освобождения на две атомарные теоретико-стойкие операции - вход и выход из операции. Неплохая инженерная задача для курсовой. Жаль, меня давно уже выпустили

-- 16.11.2015, 22:31 --

slavav в сообщении #1074103 писал(а):

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

Так примерно так оно сейчас и работает. И чем дальше, тем чаще приходится анализировать, как эти специализированные аллокаторы поживают и не поехало ли там чего наперекосяк, сводя на нет оптимизации - а хочется вместо этого делом заниматься =)

[bondkim137]

В общем, пока зарядил такую схему - работает 20 пулов, в каждом фиксированный размер блока. начинается с 24 байт, каждый следующий в 1.5 раза больше. каждый пул саморасширяющийся с основанием 2. остаток отдается глобальному 'медленному' менеджеру памяти, его почти нет. выбор пула происходит без глобальных локов, внутри пула есть лок, но их 20 разных. плюс пул работает за O(1). в итоге весь менеджер работает за O(1), оверхед - в среднем менее 50% (в основном из-за роста пулов с основанием 2). со скоростью пока справляется + он мультитредовый.
Это порвало по скорости встроенный менеджер памяти в GCC+debian minimal последний.

[Progger]

Пулы расширяются, пока есть память или как-то ограничены? Если в пуле нет места, то память выделяется из следующего пула или сразу используется глобальный менеджер?

[bondkim137]

Progger в сообщении #1080819 писал(а):

Пулы расширяются, пока есть память или как-то ограничены? Если в пуле нет места, то память выделяется из следующего пула или сразу используется глобальный менеджер?

пулы не ограничены. из глобального

[bondkim137]

Update: система доросла до производительности, когда стали проявляться просадки на мутексах в рамках одного банка. Не смотря на то, что действий внутри критической секции делать не много, из-за дорогих конфликтов начались проблемы. Добавили горизонтально несколько банков для каждого уровня. С горизонтальным итератором индекса без интерлока, ибо там точная работа не требуется. Кол-во банков на каждом уровне увеличивается при необходимости сторонним смотрителем, анализирующем частоту вызовов банков. Взлетело.