- 21 Nov, 2020 1 commit
-
-
The win32 leakchecking system is now named win32_leakcheck. Update the allocator to match.
Edward Thomson committed
-
- 21 Feb, 2019 2 commits
-
-
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 -
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
-
- 07 Jun, 2018 3 commits
-
-
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 -
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 -
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
-