forked from git-for-windows/git
-
Notifications
You must be signed in to change notification settings - Fork 92
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Teach git the ability to allocate a block of memory upfront and manually manage it Git often needs to manage the memory for many instances of small structs, for example cache_entrys. It allocates memory for each instance of a cache_entry struct individually. While this makes it easier to manage, repeatedly allocating small amounts of memory performance implications. It might be more efficient to allocate a large chunk of memory and manage instances from this block. This improved performance can come with restrictions in how the memory is managed. Overview This change has several parts: - Move the existing memory pool type into a more generalized and accessible structure - Add an API to allocate / free cache_entry instances and have all cache_entry allocations go through this API. - Have the cache_entry allocation API allocate memory from a mem_pool as appropriate. Split Index Overview One challenge is handling memory management, especially in the presence of split index mode. In split index mode, the majority of the cache entries are stored in a separate file on disk (referred to as the split index file) while the $GIT_DIR/index file stores modifications to apply. In Split index mode, there are 2 related constructs: - The on disk storage of the index: - $GIT_DIR/index: stores modifications to apply to the entries in the split index file - Split index file: stores the majority of the cache entries. - The in memory representation of the index: - the_index: Represents the logical view of the index. - split_index: Represents the view of the "base" cache entries that will be written to the split index file. Cache Entry Lifetime There was not a strong notion about who owns the lifetimes of these objects. These objects are not ref counted and can be referenced by both the_index and the split_index. The lifetime of these objects was managed by following rules: - the_index can reference a single split_index. - the_index can reference cache_entrys linked to the split_index - the split_index can be referenced by multiple other indexs, and is ref counted. - the_index is discarded before the corresponding split_index - When discarding the_index, it will free cache_entries that it refers to as long as the cache_entry is not linked with the split index Memory Pool Design We introduce the concept of a memory pool from which cache entries will be allocated. Every instance of an index will have an associated memory pool. A memory pool is associated with a single index. When an index is discarded, the associated memory pool and its allocated cache_entrys are freed. The lifetime of a memory pool and the associated cache_entries are tied to an index. (Note, in some special cases, we can move the memory pool to another index). An index can reference cache_entries allocated by its memory pool, or by the memory pool of the associated split index. The split index has a longer lifetime than the_index. The split_index can be shared with multiple "parent" indexes This layering, where cache_entries can be shared by a split_index to a "parent" index, but not the other way around) means we can free a memory pool and the cache entries allocated from it when we discard the associated index. When allocating cache_entrys in split index mode, they need to be allocated from the memory pool associated with the split index, as these cache entries can be applied to both the the_index and the split_index. Signed-off-by: Jameson Miller <jamill@microsoft.com>
- Loading branch information
Showing
18 changed files
with
474 additions
and
153 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.