1. 21 Nov, 2020 1 commit
  2. 21 Feb, 2019 2 commits
    • allocators: extract crtdbg allocator into its own file · 48727e5d
      The Windows-specific crtdbg allocator is currently mixed into the
      crtdbg stacktracing compilation unit, making it harder to find
      than necessary. Extract it and move it into the new "allocators/"
      subdirectory to improve discoverability.
      
      This change means that the crtdbg compilation unit is now
      compiled unconditionally, whereas it has previously only been
      compiled on Windows platforms. Thus we now have additional guards
      around the code so that it will only be compiled if
      GIT_MSVC_CRTDBG is defined. This also allows us to move over the
      fallback-implementation of `git_win32_crtdbg_init_allocator` into
      the same compilation unit.
      Patrick Steinhardt committed
    • allocators: move standard allocator into subdirectory · b63396b7
      Right now, our two allocator implementations are scattered around
      the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h".
      Start grouping them together in a single directory "allocators/",
      similar to how e.g. our streams are organized.
      Patrick Steinhardt committed
  3. 07 Jun, 2018 3 commits
    • alloc: make memory allocators use function pointers · 9865cd16
      Currently, our memory allocators are being redirected to the correct
      implementation at compile time by simply using macros. In order to make
      them swappable at runtime, this commit reshuffles that by instead making
      use of a global "git_allocator" structure, whose pointers are set up to
      reference the allocator functions. Like this, it becomes easy to swap
      out allocators by simply setting these function pointers.
      
      In order to initialize a "git_allocator", our provided allocators
      "stdalloc" and "crtdbg" both provide an init function. This is being
      called to initialize a passed in allocator struct and set up its members
      correctly.
      
      No support is yet included to enable users of libgit2 to switch out the
      memory allocator at a global level.
      Patrick Steinhardt committed
    • stdalloc: extend allocators by file and line · 08b318c0
      Our desired architecture would make allocators completely pluggable,
      such that users of libgit2 can swap out memory allocators at runtime.
      While making e.g. debugging easier by not having to do a separate build,
      this feature can also help maintainers of bindings for libgit2 by tying
      the memory allocations into the other language's memory system.
      
      In order to do so, though, we first need to make our two different
      pre-existing allocators "stdalloc" and "crtdbg" have the same function
      signatures, as the "crtdbg" allocators all have an additional file and
      line argument. This is required to build correct stack traces for
      debugging memory allocations. As that feature may also be interesting to
      authors of other applications for debugging libgit2, we now simply add
      these arguments to our standard allocators.
      
      Obviously, this may come with a performance penalty. During some simple
      benchmarks no real impact could be measured though in contrast to a
      simple pluggable allocator. The following table summarizes the
      benchmarks. There were three different builds with our current standard
      allocator ("standard"), with pluggable authenticators accessed via
      function pointers ("pluggable") and for pluggable authenticators with
      file and line being added ("fileline"). Furthermore, there were three
      scenarios for 100.000.000 allocations of 100B ("small alloc"),
      100.000.000 allocations of 100KB ("medium alloc"), and 1.000.000
      allocations of 100MB. All results are best of 10 runs.
      
      |------------|-------------------|-------------------|-------------------|
      | build/test | small alloc       | medium alloc      | big alloc         |
      |------------|-------------------|-------------------|-------------------|
      | standard   | 4539779566, +0.0% | 5912927186, +0.0% | 5166935308, +0.0% |
      |------------|-------------------|-------------------|-------------------|
      | pluggable  | 4611074505, +1.5% | 5979185308, +1.1% | 5388776352, +4.2% |
      |------------|-------------------|-------------------|-------------------|
      | fileline   | 4588338192, +1.1% | 6004951910, +1.5% | 4942528135, -4.4% |
      |------------|-------------------|-------------------|-------------------|
      
      As can be seen, there is a performance overhead for pluggable
      allocators. Furthermore, it can also be seen that there is some big
      variance between runs, especially in the "big alloc" scenario. This is
      probably being caused by nondeterministic behaviour in the kernel for
      dynamic allocations. Still, it can be observed that there should be no
      real difference between the "pluggable" and "fileline" allocators.
      Patrick Steinhardt committed
    • util: extract `stdalloc` allocator into its own module · c47f7155
      Right now, the standard allocator is being declared as part of the
      "util.h" header as a set of inline functions. As with the crtdbg
      allocator functions, these inline functions make it hard to convert to
      function pointers for our allocators.
      
      Create a new "stdalloc" module containing our standard allocations
      functions to split these out. Convert the existing allocators to macros
      which make use of the stdalloc functions.
      Patrick Steinhardt committed