Skip to content

G
git2
Switch branch/tag
  1. 07 Jun, 2018 8 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 allocators into its own "alloc.h" header · d2e996fa 
      Our "util.h" header is a grabbag of various different functions, where
many don't have a clear group they belong to. Our set of allocator
functions though can be clearly singled out as a single group of
functions that always belongs together. Furthermore, we will need to
implement additional functions relating to our allocators subsystem when
moving to pluggable allocators. Thus, we should just move these
functions into their own "alloc" module.
      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
    • win32: crtdbg: provide independent `free` function · 496b0df2 
      Currently, the `git__free` function is being defined in a single place,
only, disregarding whether we use our standard allocators or the crtdbg
allocators. This makes it a bit harder to convert our code base to use
pluggable allocators, and furthermore makes the border between our two
allocators a bit more blurry.

Implement a separate `git__crtdbg__free` function for the crtdbg
allocator in order to completely separate both allocator
implementations.
      Patrick Steinhardt committed
    • win32: crtdbg: internalize implementation of allocators · aab8f87b 
      The crtdbg allocators are currently being implemented as inline
functions as part of the "w32_crtdbg_stacktrace.h" header. As we are
moving towards pluggable allocators with the help of function pointers,
though, we cannot make use of inlining anymore. Instead, we can only
have a single implementation of these allocating functions.

Move all implementations of the crtdbg allocators into
"w32_crtdbg_stacktrace.c".
      Patrick Steinhardt committed
    • Merge pull request #4655 from glaubitz/alignment · 422cd59b 
      index: Fix alignment issues in write_disk_entry()
      Patrick Steinhardt committed
    • Merge pull request #4558 from tiennou/travis/war-on-leaks · 534b70af 
      travis: war on leaks
      Patrick Steinhardt committed
  3. 06 Jun, 2018 15 commits
  5. 01 Jun, 2018 4 commits
  7. 30 May, 2018 7 commits
  9. 29 May, 2018 2 commits
  11. 25 May, 2018 2 commits
  13. 24 May, 2018 2 commits