1 | //===-- xray_profile_collector.h -------------------------------*- C++ -*-===// |
2 | // |
3 | // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. |
4 | // See https://llvm.org/LICENSE.txt for license information. |
5 | // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception |
6 | // |
7 | //===----------------------------------------------------------------------===// |
8 | // |
9 | // This file is a part of XRay, a dynamic runtime instrumentation system. |
10 | // |
11 | // This file defines the interface for a data collection service, for XRay |
12 | // profiling. What we implement here is an in-process service where |
13 | // FunctionCallTrie instances can be handed off by threads, to be |
14 | // consolidated/collected. |
15 | // |
16 | //===----------------------------------------------------------------------===// |
17 | #ifndef XRAY_XRAY_PROFILE_COLLECTOR_H |
18 | #define XRAY_XRAY_PROFILE_COLLECTOR_H |
19 | |
20 | #include "xray_function_call_trie.h" |
21 | |
22 | #include "xray/xray_log_interface.h" |
23 | |
24 | namespace __xray { |
25 | |
26 | /// The ProfileCollectorService implements a centralised mechanism for |
27 | /// collecting FunctionCallTrie instances, indexed by thread ID. On demand, the |
28 | /// ProfileCollectorService can be queried for the most recent state of the |
29 | /// data, in a form that allows traversal. |
30 | namespace profileCollectorService { |
31 | |
32 | /// Posts the FunctionCallTrie associated with a specific Thread ID. This |
33 | /// will: |
34 | /// |
35 | /// Moves the collection of FunctionCallTrie, Allocators, and Buffers associated |
36 | /// with a thread's data to the queue. This takes ownership of the memory |
37 | /// associated with a thread, and manages those exclusively. |
38 | /// |
39 | void post(BufferQueue *Q, FunctionCallTrie &&T, |
40 | FunctionCallTrie::Allocators &&A, |
41 | FunctionCallTrie::Allocators::Buffers &&B, tid_t TId); |
42 | |
43 | /// The serialize will process all FunctionCallTrie instances in memory, and |
44 | /// turn those into specifically formatted blocks, each describing the |
45 | /// function call trie's contents in a compact form. In memory, this looks |
46 | /// like the following layout: |
47 | /// |
48 | /// - block size (32 bits) |
49 | /// - block number (32 bits) |
50 | /// - thread id (64 bits) |
51 | /// - list of records: |
52 | /// - function ids in leaf to root order, terminated by |
53 | /// 0 (32 bits per function id) |
54 | /// - call count (64 bit) |
55 | /// - cumulative local time (64 bit) |
56 | /// - record delimiter (64 bit, 0x0) |
57 | /// |
58 | void serialize(); |
59 | |
60 | /// The reset function will clear out any internal memory held by the |
61 | /// service. The intent is to have the resetting be done in calls to the |
62 | /// initialization routine, or explicitly through the flush log API. |
63 | void reset(); |
64 | |
65 | /// This nextBuffer function is meant to implement the iterator functionality, |
66 | /// provided in the XRay API. |
67 | XRayBuffer nextBuffer(XRayBuffer B); |
68 | |
69 | } // namespace profileCollectorService |
70 | |
71 | } // namespace __xray |
72 | |
73 | #endif // XRAY_XRAY_PROFILE_COLLECTOR_H |
74 | |