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

[Dean Michael Berris via Phabricator via llvm-commits]

dberris created this revision.
dberris added reviewers: echristo, pelikan, kpw.
Herald added a subscriber: mgorny.

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`.

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.


https://reviews.llvm.org/D45756

Files:
  compiler-rt/lib/xray/CMakeLists.txt
  compiler-rt/lib/xray/tests/unit/CMakeLists.txt
  compiler-rt/lib/xray/tests/unit/allocator_test.cc
  compiler-rt/lib/xray/tests/unit/segmented_array_test.cc
  compiler-rt/lib/xray/xray_allocator.h
  compiler-rt/lib/xray/xray_segmented_array.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D45756.142886.patch
Type: text/x-patch
Size: 21530 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180418/7d5c2cdd/attachment.bin>