2018-05-31 12:33:52 +08:00
|
|
|
//===-- xray_profile_collector.h -------------------------------*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2018-05-31 12:33:52 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file is a part of XRay, a dynamic runtime instrumentation system.
|
|
|
|
//
|
|
|
|
// This file defines the interface for a data collection service, for XRay
|
|
|
|
// profiling. What we implement here is an in-process service where
|
|
|
|
// FunctionCallTrie instances can be handed off by threads, to be
|
|
|
|
// consolidated/collected.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#ifndef XRAY_XRAY_PROFILE_COLLECTOR_H
|
|
|
|
#define XRAY_XRAY_PROFILE_COLLECTOR_H
|
|
|
|
|
|
|
|
#include "xray_function_call_trie.h"
|
|
|
|
|
|
|
|
#include "xray/xray_log_interface.h"
|
|
|
|
|
|
|
|
namespace __xray {
|
|
|
|
|
|
|
|
/// The ProfileCollectorService implements a centralised mechanism for
|
|
|
|
/// collecting FunctionCallTrie instances, indexed by thread ID. On demand, the
|
|
|
|
/// ProfileCollectorService can be queried for the most recent state of the
|
|
|
|
/// data, in a form that allows traversal.
|
|
|
|
namespace profileCollectorService {
|
|
|
|
|
|
|
|
/// Posts the FunctionCallTrie associated with a specific Thread ID. This
|
|
|
|
/// will:
|
|
|
|
///
|
[XRay] Use preallocated memory for XRay profiling
Summary:
This change builds upon D54989, which removes memory allocation from the
critical path of the profiling implementation. This also changes the API
for the profile collection service, to take ownership of the memory and
associated data structures per-thread.
The consolidation of the memory allocation allows us to do two things:
- Limits the amount of memory used by the profiling implementation,
associating preallocated buffers instead of allocating memory
on-demand.
- Consolidate the memory initialisation and cleanup by relying on the
buffer queue's reference counting implementation.
We find a number of places which also display some problematic
behaviour, including:
- Off-by-factor bug in the allocator implementation.
- Unrolling semantics in cases of "memory exhausted" situations, when
managing the state of the function call trie.
We also add a few test cases which verify our understanding of the
behaviour of the system, with important edge-cases (especially for
memory-exhausted cases) in the segmented array and profile collector
unit tests.
Depends on D54989.
Reviewers: mboerger
Subscribers: dschuff, mgorny, dmgreen, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D55249
llvm-svn: 348568
2018-12-07 14:23:06 +08:00
|
|
|
/// Moves the collection of FunctionCallTrie, Allocators, and Buffers associated
|
|
|
|
/// with a thread's data to the queue. This takes ownership of the memory
|
|
|
|
/// associated with a thread, and manages those exclusively.
|
2018-05-31 12:33:52 +08:00
|
|
|
///
|
[XRay] Use preallocated memory for XRay profiling
Summary:
This change builds upon D54989, which removes memory allocation from the
critical path of the profiling implementation. This also changes the API
for the profile collection service, to take ownership of the memory and
associated data structures per-thread.
The consolidation of the memory allocation allows us to do two things:
- Limits the amount of memory used by the profiling implementation,
associating preallocated buffers instead of allocating memory
on-demand.
- Consolidate the memory initialisation and cleanup by relying on the
buffer queue's reference counting implementation.
We find a number of places which also display some problematic
behaviour, including:
- Off-by-factor bug in the allocator implementation.
- Unrolling semantics in cases of "memory exhausted" situations, when
managing the state of the function call trie.
We also add a few test cases which verify our understanding of the
behaviour of the system, with important edge-cases (especially for
memory-exhausted cases) in the segmented array and profile collector
unit tests.
Depends on D54989.
Reviewers: mboerger
Subscribers: dschuff, mgorny, dmgreen, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D55249
llvm-svn: 348568
2018-12-07 14:23:06 +08:00
|
|
|
void post(BufferQueue *Q, FunctionCallTrie &&T,
|
|
|
|
FunctionCallTrie::Allocators &&A,
|
|
|
|
FunctionCallTrie::Allocators::Buffers &&B, tid_t TId);
|
2018-05-31 12:33:52 +08:00
|
|
|
|
|
|
|
/// The serialize will process all FunctionCallTrie instances in memory, and
|
|
|
|
/// turn those into specifically formatted blocks, each describing the
|
|
|
|
/// function call trie's contents in a compact form. In memory, this looks
|
|
|
|
/// like the following layout:
|
|
|
|
///
|
|
|
|
/// - block size (32 bits)
|
|
|
|
/// - block number (32 bits)
|
|
|
|
/// - thread id (64 bits)
|
|
|
|
/// - list of records:
|
|
|
|
/// - function ids in leaf to root order, terminated by
|
|
|
|
/// 0 (32 bits per function id)
|
|
|
|
/// - call count (64 bit)
|
|
|
|
/// - cumulative local time (64 bit)
|
|
|
|
/// - record delimiter (64 bit, 0x0)
|
|
|
|
///
|
|
|
|
void serialize();
|
|
|
|
|
|
|
|
/// The reset function will clear out any internal memory held by the
|
|
|
|
/// service. The intent is to have the resetting be done in calls to the
|
|
|
|
/// initialization routine, or explicitly through the flush log API.
|
|
|
|
void reset();
|
|
|
|
|
|
|
|
/// This nextBuffer function is meant to implement the iterator functionality,
|
|
|
|
/// provided in the XRay API.
|
|
|
|
XRayBuffer nextBuffer(XRayBuffer B);
|
|
|
|
|
2018-05-31 12:55:11 +08:00
|
|
|
} // namespace profileCollectorService
|
2018-05-31 12:33:52 +08:00
|
|
|
|
|
|
|
} // namespace __xray
|
|
|
|
|
|
|
|
#endif // XRAY_XRAY_PROFILE_COLLECTOR_H
|