{"id":64,"date":"2017-04-07T15:54:33","date_gmt":"2017-04-07T19:54:33","guid":{"rendered":"https:\/\/cyberbisson.com\/blog\/?p=64"},"modified":"2021-07-22T21:36:36","modified_gmt":"2021-07-23T01:36:36","slug":"an-exploration-of-the-deleter-on-the-memory-footprint-of-stdunique_ptr","status":"publish","type":"post","link":"https:\/\/cyberbisson.com\/blog\/2017\/04\/07\/an-exploration-of-the-deleter-on-the-memory-footprint-of-stdunique_ptr\/","title":{"rendered":"An Exploration of the Deleter on the Memory Footprint of std::unique_ptr<\/tt>"},"content":{"rendered":"

<\/p>\n

\n\n<\/div>\n

(\u2026or \u201cHow I Learned to Love the Tuple.\u201d)<\/p>\n

Although the C++ standard does not explicitly spell it out, one may hope for a sophisticated implementation of the std::unique_ptr<\/tt> that consumes exactly as much memory as the pointer it tracks when it is configured to use a empty-class deleter (such as the default deleter type). The unique_ptr<\/tt> indeed allows the consumer to supply a custom deleter, which one intuitively expects to consume memory\u2009\u2014\u2009if you store two pieces of data, you will consume two spots in memory somehow, right? Not quite. I will explore how this is done (specifically in GCC).<\/p>\n

<\/p>\n\n

A Na\u00efve Implementation<\/h1>\n

Once upon a time, I wrote a handle container type, similar to unique_ptr<\/tt>. In fact, I called this unique_handle<\/tt> (you can see it here<\/a>). Because I wanted to optimize for my most common case\u2009\u2014\u2009a simple CloseHandle()<\/tt>\u2009\u2014\u2009I optimized the container as suggested above. If the caller used the default deleter, no unique_handle<\/tt> instance should consume more memory than the handle itself.<\/p>\n

I achieved this behavior with template specialization. The generic unique_handle<\/tt> class template had storage for the deleter alongside the handle itself. I then provided a specific specialization for unique_handle<\/tt> that was given the default deleter (specified as a default template parameter). Unfortunately, specializing a class requires duplication of various bits of code, so the unique_handle<\/tt> type had a base class for common code, and two user-visible implementation types, adding to the overall complexity.<\/p>\n

Another downside to this approach is the fact that only<\/em> the recognized deleter type resulted in a smaller footprint. Even using a deleter derived from the default one resulted in increased size.<\/p>\n

What GCC Produces<\/h1>\n

Our wishes become reality, because I can show that unique_ptr<\/tt> does<\/em> consume the minimum possible size in GCC, as I suggested a \u201cgood\u201d implementation would. Consider the following test code:<\/p>\n

\/\/ Here is the memory we will track with std::unique_ptr.\nstruct blob {\n    int something = 0;\n};\n\n\/\/ This is a deleter that takes no space.\nstruct delete_blob_empty {\n    void operator()(blob *const in) const noexcept {\n        delete in;\n    }\n};\n\n\/\/ This deleter has state -- essentially, should we zero out the pointer after\n\/\/ deletion.\nstruct delete_blob {\n    bool null_it = false;\n    void operator()(blob *in) const noexcept {\n        delete in;\n        if (null_it) in = nullptr;\n    }\n};\n\nint main()\n{\n    delete_blob my_deleter;\n    delete_blob_empty my_empty_deleter;\n\n    std::unique_ptr<blob> some_blob(new blob);\n    std::unique_ptr<blob, delete_blob> custom_blob(new blob, my_deleter);\n    std::unique_ptr<blob, delete_blob_empty> empty_custom_blob(\n        new blob, my_empty_deleter);\n\n    std::cout << \"Sizes: some_blob = \"    << sizeof(some_blob)\n              << \"; custom_blob = \"       << sizeof(custom_blob)\n              << \"; empty_custom_blob = \" << sizeof(empty_custom_blob)\n              << '\\n';\n\n    std::cout << \"Done!\\n\";\n    return 0;\n}\n<\/pre>\n
Which prints:<\/p>\n
Sizes: some_blob = 8 custom_blob = 16 empty_custom_blob = 8\nDone!\n<\/pre>\n
Great!  The only unique_ptr<\/tt> that consumes 16 bytes (this is a 64-bit system, so the size of a pointer will be 8 bytes) is the one that contains a custom deleter that has state (delete_blob<\/tt>).  This means that not only have they addressed the default deleter case, as I had in unique_handle<\/tt>, but they even detect custom deleters that don\u2019t consume space, and react accordingly.<\/p>\n
How Is It Implemented?<\/h1>\n
How is GCC doing this?  It certainly isn\u2019t in the same manner as my earlier suggestion.  A quick search of the libstdc++<\/tt> headers (specifically, bits\/unique_ptr.h<\/tt>) shows that there is no specialization based on the deleter.  Actually the only specialization of unique_ptr<\/tt> is to support different behavior when _Tp<\/tt> (the pointer type) is a simple pointer, versus an array.  These unique_ptr<\/tt> implementations are quite succinct, and do not delegate any responsibility to implementation types.  Here\u2019s what we have:<\/p>\n
\/\/\/ 20.7.1.2 unique_ptr for single objects.\ntemplate <typename _Tp, typename _Dp = default_delete<_Tp> >\n  class unique_ptr\n<\/pre>\n
\u2026and:<\/p>\n
\/\/\/ 20.7.1.3 unique_ptr for array objects with a runtime length\n\/\/ [unique.ptr.runtime]\n\/\/ _GLIBCXX_RESOLVE_LIB_DEFECTS\n\/\/ DR 740 - omit specialization for array objects with a compile time length\ntemplate<typename _Tp, typename _Dp>\n  class unique_ptr<_Tp[], _Dp>\n<\/pre>\n
Enter the std::tuple<\/tt><\/h2>\n
The secret to all of this is how unique_ptr<\/tt> stores its data.  Back in our na\u00efve implementation, we would have simply defined two fields, one for the pointer data, and a second for the deleter.  This is not what GCC does.  In the declaration for unique_ptr<\/tt>:<\/p>\n
typedef std::tuple<typename _Pointer::type, _Dp>  __tuple_type;\n__tuple_type                                      _M_t;\n<\/pre>\n
The compiler will reduce this down ultimately to:<\/p>\n
std::tuple<blob*, std::default_delete<blob>> _M_t; \/\/ For some_blob\nstd::tuple<blob*, delete_blob> _M_t;               \/\/ For custom_blob\nstd::tuple<blob*, delete_blob_empty> _M_t;         \/\/ For empty_custom_blob\n<\/pre>\n
So this means the magic is actually somewhere in std::tuple<\/tt>.  This implication is great, and it means that not only are the entire class of unique_ptr<\/tt> instances memory optimized to store only what\u2019s required, but anything that uses std::tuple<\/tt> automatically strips away types that require no in-memory footprint, while still giving you access to their facilities.<\/em>  I will restate this another way: we have asked to store two pieces of information, and we can still use all the functions of both pieces of data, but only one actually takes memory resources.  A simple struct<\/tt>, or even std::pair<\/tt> cannot make this promise.<\/p>\n
The std::tuple<\/tt> class template (found in the header file, tuple<\/tt>) consists of a recursively-defined variadic template that forwards to a type called _Tuple_impl<\/tt>.  Most of _Tuple_impl<\/tt>\u2019s purpose is to keep track of the position in the tuple<\/tt> of the current element, and to break off a type from the template parameter pack, handing it to _Head_base<\/tt>.<\/p>\n
Finally, with _Head_base<\/tt> we see some template specialization.  Here is the (empty) class template declaration.<\/p>\n
template<std::size_t _Idx, typename _Head, bool _IsEmptyNotFinal>\n  struct _Head_base;\n<\/pre>\n
Pay close attention to this third template parameter, _IsEmptyNotFinal<\/tt>.  _Head_base<\/tt> has these two specializations:<\/p>\n
template<std::size_t _Idx, typename _Head>\n  struct _Head_base<_Idx, _Head, true>\n  : public _Head\n  {\n    constexpr _Head_base()\n    : _Head() { }\n\n    constexpr _Head_base(const _Head& __h)\n    : _Head(__h) { }\n\n    \/\/ ... [MB] Interface omitted ...\n  };\n\ntemplate<std::size_t _Idx, typename _Head>\n  struct _Head_base<_Idx, _Head, false>\n  {\n    constexpr _Head_base()\n    : _M_head_impl() { }\n\n    constexpr _Head_base(const _Head& __h)\n    : _M_head_impl(__h) { }\n\n    \/\/ ... [MB] Interface omitted ...\n\n    _Head _M_head_impl;\n  };\n<\/pre>\n
Simply put, if we get an _IsEmptyNotFinal<\/tt> that is true<\/tt>, the class that\u2019s defined doesn\u2019t even have a data member.  For completeness, the std::tuple<\/tt> implementation sets this parameter by passing the pointer type to the metafunction, __empty_not_final<\/tt> (which is a topic for another day) but it essentially boils down to std::is_empty<\/tt>:<\/p>\n
template<typename _Tp>\n  struct __is_empty_non_tuple : is_empty<_Tp> { };\n\n\/\/ Using EBO for elements that are tuples causes ambiguous base errors.\ntemplate<typename _El0, typename... _El>\n  struct __is_empty_non_tuple<tuple<_El0, _El...>> : false_type { };\n\n\/\/ Use the Empty Base-class Optimization for empty, non-final types.\ntemplate<typename _Tp>\n  using __empty_not_final\n  = typename conditional<__is_final(_Tp), false_type,\n                         __is_empty_non_tuple<_Tp>>::type;\n<\/pre>\n
Note: If I make delete_blob_empty<\/tt> a final<\/tt> class, the tuple<\/tt> again takes a full 16 bytes.<\/em>  This restriction exists because _Head_base<\/tt> derives from the passed-in template type, so accepting the final<\/tt> type would result in compilation errors.<\/p>\n
In The Debugger<\/h2>\n
To get a concrete feel for how this looks in memory, let\u2019s examine it in the debugger.  If I examine the unique_ptr<\/tt> instance (from the example code) named some_blob<\/tt>, I see this (I have manually pretty-printed GDB output a little more from the basic \u201cp \/r<\/tt>\u201d output):<\/p>\n
<std::_Tuple_impl<0ul, blob*, std::default_delete<blob> >> = {\n\n    <std::_Tuple_impl<1ul, std::default_delete<blob> >> = {\n        <std::_Head_base<1ul, std::default_delete<blob>, true>> = {\n            <std::default_delete<blob>> = { },\n        },\n    },\n\n    <std::_Head_base<0ul, blob*, false>> = { _M_head_impl = 0x614c20 },\n};\n<\/pre>\n
Examining custom_blob<\/tt> looks like this:<\/p>\n
<std::_Tuple_impl<0ul, blob*, delete_blob>> = {\n\n    <std::_Tuple_impl<1ul, delete_blob>> = {\n        <std::_Head_base<1ul, delete_blob, false>> = {\n            _M_head_impl = { null_it = false }\n        },\n    },\n\n    <std::_Head_base<0ul, blob*, false>> = { _M_head_impl = 0x614c40 },\n}\n<\/pre>\n
Pay close attention to the _Head_base<\/tt>\u2019s third parameter, the boolean value we know as _IsEmptyNotFinal<\/tt>.  The only field that std::tuple<\/tt> places into memory is _M_head_impl<\/tt>, and we can see that a value of true<\/tt> elides the creation of this data in memory.<\/p>\n
It is also worth noticing that tuple<\/tt> reverses the in-memory ordering of its data.  This is because the implementation class defines the \u201ctail\u201d of the data-structure as its base class, stashing the \u201chead\u201d into the derived class.  As you likely already know, the layout of a class is such that the base classes exist first, and derived classes append any new fields past the end of the base class.  For our unique_ptr<\/tt> use-case, this means that we need to be a bit careful:<\/p>\n