[Из песочницы] std::shared_ptr и кастомный аллокатор28.06.2016 15:33

Кто из нас не любит рефакторинг? Думаю, что неоднократно каждый из нас при рефакторинге старого кода открывал для себя что-то новое или вспоминал что-то важное, но хорошо забытое. Совсем недавно, несколько освежив свои знания работы std: shared_ptr при использовании пользовательского аллокатора, я решил что больше забывать их не стоит. Всё что удалось освежилось собрал в этой статье.

В одном из проектов потребовалось провести оптимизацию производительности. Профилирование указало на большое количество вызовов операторов new/delete и соответствующих вызовов malloc/free, которые не только приводят к дорогим блокировкам в многопоточной среде сами по себе, но и могут вызывать такие тяжелые функций как malloc_consolidate в самый неожиданный момент. Большое количество операций с динамической памятью было обусловлено интенсивной работой с умными указателями std: shared_ptr.

Классов, объекты которых создавались указанным образом, оказалось не много. Кроме того, не хотелось сильно переписывать приложение. Поэтому было принято решение исследовать возможность использования паттерна — object pool. Т.е. оставить использование shared_ptr, но переделать механизм выделения памяти таким образом, чтобы избавиться от интенсивного получения/освобождения динамической памяти.

Замену стандартной реализации malloc на другие варианты (tcmalloc, jemalloc) не рассматривали, т.к. по опыту замена стандартной реализации принципиально на производительность не влияла, а вот изменения коснулись бы всей программы с возможными последствиями.

В дальнейшем идея трансформировалась в использование собственного пула памяти и реализацию специального аллокатора. Преимуществом использования memory pool в моем случае перед object pool — прозрачность для вызывающего кода. При использовании аллокатора объекты будут размещаться в уже выделенной памяти (будет использоваться размещающий оператор new) с соответствующим вызовом конструктора, а так же очищаться явным вызовов деструктора. Т.е. дополнительных действий, которые характерны для object pool, для инициализации объекта (при получении из пула) и для приведения его в исходное состояние (перед возвращением в пул) выполнять не требуется.

Далее я рассмотрю какие интересные особенности работы с памятью при использовании shared_ptr лично я для себя уяснил и разложил по полочкам. Чтобы не перегружать текст деталями, код будет упрощенными и к реальному проекту будет относиться только в самых общих чертах. В первую очередь я буду фокусироваться не на реализации аллокатора, а на принципе работы с std: shared_ptr при ипользовании кастомного алокатора.

Текущим механизмом создания указателя было использование std: make_shared:

auto ptr = std::make_shared();

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

auto ptr = std::shared_ptr(new foo_struct);

Ключевая идея в работе с памятью std: shared_ptr в порядке создания управляющего блока. А мы знаем, что это специальная структура, которая и делает указатель умным. И для неё нужно соответственно честно выделить память.

Возможность полностью контролировать использование памяти при работе с std: shared_ptr нам предоставляется через std: allocate_shared. При вызове std: allocate_shared можно передать собственный аллокатор:

auto ptr = std::allocate_shared(allocator);

Если переопределить операторы new и delete, то можно посмотреть как происходит выделение нужного объема памяти для структуры из примера:

struct foo_struct
{
    foo_struct()
    {
        std::cout << "foo_struct()" << std::endl;
    }

    ~foo_struct()
    {
        std::cout << "~foo_struct()" << std::endl;
    }

    uint64_t value1 = 1;
    uint64_t value2 = 2;
    uint64_t value3 = 3;
    uint64_t value4 = 4;
};

Возьмем для примера простейший аллокатор:

template 
struct custom_allocator {
    typedef T value_type;
    custom_allocator() noexcept {}
    template  custom_allocator (const custom_allocator&) noexcept {}
    T* allocate (std::size_t n) {
        return reinterpret_cast( ::operator new(n*sizeof(T)));
    }
    void deallocate (T* p, std::size_t n) {
        ::operator delete(p);
    }

};

---- Construct shared ----
operator new: size = 32 p = 0x1742030
foo_struct()
operator new: size = 24 p = 0x1742060
~foo_struct()
operator delete: p = 0x1742030
operator delete: p = 0x1742060
---- Construct shared ----

---- Make shared ----
operator new: size = 48 p = 0x1742080
foo_struct()
~foo_struct()
operator delete: p = 0x1742080
---- Make shared ----

---- Allocate shared ----
operator new: size = 48 p = 0x1742080
foo_struct()
~foo_struct()
operator delete: p = 0x1742080
---- Allocate shared ----

---- Allocate shared ----
Allocating: std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>
operator new: size = 48 p = 0x1742080
foo_struct()
~foo_struct()
Deallocating: std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>
operator delete: p = 0x1742080
---- Allocate shared ----

---- Allocate shared ----
sizeof control_block_type: 48
sizeof foo_struct: 32
custom_allocator::custom_allocator(const custom_allocator&): 
    T: std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>
    U: foo_struct
Allocating: std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>
operator new: size = 48 p = 0x1742080
foo_struct()
~foo_struct()
custom_allocator::custom_allocator(const custom_allocator&): 
    T: std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>
    U: foo_struct
Deallocating: std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>
operator delete: p = 0x1742080
---- Allocate shared ----

using control_block_type = std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>;
constexpr static size_t block_size = sizeof(control_block_type);