Skip to content

Conversation

@eparshut
Copy link
Contributor

Summary

This PR addresses frequent users requests about implementing custom ITT API collectors that properly handle all ITT objects in complex application scenarios. Two common challenges they face:

  • Multiple static ITT parts - Applications where multiple libraries each statically link the ITT API, resulting in multiple __itt_global* pointers with separate object lists. Without proper handling, a collector would miss ITT events from some static parts.
  • Objects created before collector loads - ITT objects (domains, string handles, counters, histograms) may be created during static initialization, before the collector library is loaded. These pre-existing objects would be missed by a collector that only tracks objects created after initialization.

To address these requests, we enhanced the reference collector with:

  • Object spilling mechanism - The collector maintains its own unified object lists (g_ref_collector_global). During __itt_api_init(), objects already present in each static part are "spilled" (copied) into the collector's lists via spill_static_part_lists(). This ensures that all ITT objects across all static parts are aggregated into a single view and objects created before collector initialization are not missed.
  • Developer documentation - Added inline comments throughout the code to help customers understand the key extension points and patterns when building their own collectors.

Changes:

  • Added g_ref_collector_global structure with collector-owned object lists
  • Implemented spill_static_part_lists() to copy pre-existing objects from each static part during __itt_api_init()
  • Added support for region APIs and different counter create APIs
  • Added documentation comments for key functions and extension points
  • Fixed some minor typos / issues

@eparshut eparshut requested a review from a team December 23, 2025 16:08
__itt_histogram* histogram_list;
} g_ref_collector_global = {MUTEX_INITIALIZER, 0, NULL, NULL, NULL, NULL};

static char* log_file_name_generate()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it is better to name it generate_log_file_name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree but the current name follows the existing naming convention in this source file where verbs come at the end: ref_collector_init, ref_collector_release, fill_func_ptr_per_lib, etc. changing just this function would break consistency.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just don't want to rename them all

if (!g_ref_collector_global.mutex_initialized) return;

__itt_mutex_lock(&(g_itt_global->mutex));
__itt_mutex_lock(&g_ref_collector_global.mutex);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any possibility that ref_collector_release will be called from different threads?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by design, there's no multi-threaded scenario for this function.

@eparshut eparshut merged commit 52a098d into intel:master Dec 23, 2025
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants