Tcmalloc of Go language memory allocation

This is a creation in Article, where the information may have evolved or changed.

Tcmalloc

Tcmalloc Advantages

• Fast, faster than GLICBC 2.3
• Consumes less memory space, 8 times times 8-byte Object memory allocation occupies approximately 8n*1.01byte of the head space, while Ptmalloc occupies 16n*byte's head space

Use

• Only use the "-ltmalloc" Connection ID in your program to link it to your program

Review

• Tcmalloc allocates a local cache for each thread to meet the needs of the small object assignment, and when needed, the object moves from the central data structure to the local cache, and the periodic garbage collection reclaims the central data structure from the local cache of each thread.
  

Small object Assignment

• Each small object is mapped to 170 different size spaces. Each space interval is 8byte,0-8byte (8), 8-24byte (+), 24-48byte (24), and the maximum interval is 256byte. The bounds of large objects and small objects are 32kb. The cache for each thread consists of a series of linked tables with different sizes of idle objects connected together.
  
• When assigning a small object
  
  1. Map its size to the corresponding set of spaces first
  2. Finds the current thread thread cache idle linked list
  3. If the free list is not empty, then the first object is fetched back to the caller, and Tcmalloc does not need to be locked when it acquires space. Lock and unlock this pair of operations takes up to 100 nanoseconds on the 2.8 GHz Xeon processor, so this mechanism can effectively speed up memory allocation efficiency.
  4. If the list is empty, some objects are taken out of the central idle chain and populated into the corresponding collection (the central idle chain is shared with all threads).
  5. Place it on a thread-local idle chain
  6. Returns these new objects to the calling program.
  7. If the central buffer idle chain is also empty;
  8. Apply a continuous page to the central page allocator
  9. Split a page into a series of objects of different sizes
  10. Put these objects into the central idle list
  11. Put some of these objects into the thread local cache.
      

Large Object Assignment

• The size of a large object (greater than 32K) is aligned upward by the page size (4K) and is handled by the central page heap. The central page heap is also an array of linked lists of elements of different sizes. For I less than 256, the entry of k in the array is an idle linked list of elements of K pages that are linked together. The No. 256 entry is an idle linked list that is linked together by a length greater than 256 pages.
  
• An allocation request that requires a K page size can be satisfied by accessing the K-free list. If the idle list is empty, we will access the next free list (larger pages), and so on. Finally, we will access the last idle chain if needed. If this series of lookups fail, we will get the memory from the system (using SBRK,MMAP or by mapping part of the/dev/mem). If the allocation request for a K page size is allocated to more than K pages, it needs to be placed back into the free linked list of the corresponding size in the page heap when the space is released.

Spans

• The heap management mechanism of tcmalloc is to combine a collection of pages with a contiguous set of pages called a span object. Span can be either assigned or freed. If released, span will be placed in the corresponding page heap list. If assigned, span can be a large object to the application, or a set of pages that are split into contiguous small objects. If it is split into small objects, the size level of the object is recorded in span. The index of the page number of the central array, which can be used to implement which pages consist of finding a span. For example, span a occupies 2 pages, SPANB occupies 1 pages, span C occupies 5 pages, and span D occupies 3 pages.
  
• A 32-bit address space can be allocated 2^20 4K of pages, so the central array occupies 4MB of memory space is acceptable. On a 64-bit machine, we use a 3-level base tree instead of an array to map the page number to the corresponding span pointer.

Object Release

• When the object is disposed, the calculator page is good and finds its corresponding span in the central array. span contains information about an object, and you can tell if the object is a small object. If it is a small object, it is put back in the idle list of thread caches. If the thread's cache exceeds the predetermined size (default 2MB), the garbage collector is run to put objects that are not used by the current thread back to the freelist of Central.
• If the disposed object is a large object, the span can be used to get the object containing the page range. The upper and lower bounds of the page range lookup range, and if the upper and lower bound pages are also free, put them together in the page manager of the heap.

Small Object Central Idle chain

• Each central idle chain contains a two-level data structure: a series of spans and an idle list of idle objects in span.
• When a central idle list allocates an object, it is implemented by moving a list of spans to the first object, and if all spas have free linked lists, select the appropriate size span to allocate.
• An object is returned to the central idle chain and is implemented by hanging it into the linked list to which span belongs. If the length of the list is exactly equal to the number of all the small objects in span, the span is completely idle and needs to be returned to the page heap.

Thread Cache garbage Collection

• When all idle objects in the thread cache are under 2MB, the garbage collection period is automatically reclaimed, and when the number of threads increases, the garbage collection threshold is reduced to avoid wasted memory.
• We iterate through all the idle lists in the cache, moving a certain number of objects into the corresponding central linked list. The low water mark L for each chain determines the number of objects removed from the idle chain. L RECORDS the minimum length of the chain since the last garbage collection operation. Note that we can shorten the length of the chain by removing the L objects from the previous garbage collection and not getting other objects from the central chain. We use this past record to predict the future situation, removing the L/2 objects from the thread cache into the central chain. This algorithm performs well, and if a thread stops using an object of a particular size, all objects of that size are quickly migrated from the thread cache to the central idle chain for use by other threads.

Reference content