[XRay][profiler] Part 1: XRay Allocator and Array Implementations

Authored by dberris on Apr 29 2018, 6:46 AM.


[XRay][profiler] Part 1: XRay Allocator and Array Implementations

This change is part of the larger XRay Profiling Mode effort.

Here we implement an arena allocator, for fixed sized buffers used in a
segmented array implementation. This change adds the segmented array
data structure, which relies on the allocator to provide and maintain
the storage for the segmented array.

Key features of the Allocator type:

  • It uses cache-aligned blocks, intended to host the actual data. These blocks are cache-line-size multiples of contiguous bytes.
  • The Allocator has a maximum memory budget, set at construction time. This allows us to cap the amount of data each specific Allocator instance is responsible for.
  • Upon destruction, the Allocator will clean up the storage it's used, handing it back to the internal allocator used in sanitizer_common.

Key features of the Array type:

  • Each segmented array is always backed by an Allocator, which is either user-provided or uses a global allocator.
  • When an Array grows, it grows by appending a segment that's fixed-sized. The size of each segment is computed by the number of elements of type T that can fit into cache line multiples.
  • An Array does not return memory to the Allocator, but it can keep track of the current number of "live" objects it stores.
  • When an Array is destroyed, it will not return memory to the Allocator. Users should clean up the Allocator independently of the Array.
  • The Array type keeps a freelist of the chunks it's used before, so that trimming and growing will re-use previously allocated chunks.

These basic data structures are used by the XRay Profiling Mode
implementation to implement efficient and cache-aware storage for data
that's typically read-and-write heavy for tracking latency information.
We're relying on the cache line characteristics of the architecture to
provide us good data isolation and cache friendliness, when we're
performing operations like searching for elements and/or updating data
hosted in these cache lines.

Reviewers: echristo, pelikan, kpw

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D45756

llvm-svn: 331141