MOD-9881 Track shared SVS thread pool memory & expose it through public API

[meiravgri]

The shared VecSimSVSThreadPool singleton was previously created via raw new with the default allocator, so its slot vector and per-slot ThreadSlot objects bypassed VecSimAllocator and were invisible to any memory accounting downstream (FT.INFO, INFO MODULES, etc.).

This PR:

1. Routes the shared SVS thread pool's allocations through a dedicated VecSimAllocator (using VecsimSTLAllocator for the slot vector and std::allocate_shared for thread objects).
2. Adds a new public API size_t VecSim_GetGlobalMemory(void) returning the total bytes of process-wide VecSim allocations not tied to any single index — today equal to the shared SVS thread pool's tracked allocation size.
3. Surfaces these bytes in VECSIM_INFO via two new fields:
   • GLOBAL_MEMORY — appended at the top level of every algorithm's debug response by the C API wrapper VecSimIndex_DebugInfoIterator. Always present (value may be 0).
   • SHARED_SVS_THREADPOOL_MEMORY — appended at the end of any SVS algorithm section by SVSIndex::debugInfoIterator(). Present at the top level of a non-tiered SVS response, or inside BACKEND_INDEX of a tiered SVS response.

---

Public API change

Before

// (no API to query process-wide VecSim memory)

After

// Returns total bytes of process-wide VecSim allocations not tied to any single
// index (today: the shared SVS thread pool singleton). Returns 0 when no such
// global allocations exist.
size_t VecSim_GetGlobalMemory(void);

Callers (e.g. RediSearch) can fold this into per-spec or process-wide memory metrics without depending on which algorithm contributes.

---

VECSIM_INFO (FT.DEBUG) output change

Common header (every algorithm, unchanged)

ALGORITHM, TYPE, DIMENSION, METRIC, IS_MULTI_VALUE, IS_DISK,
INDEX_SIZE, INDEX_LABEL_COUNT, MEMORY, LAST_SEARCH_MODE

FLAT — 11 → 12 fields

  <common header × 10>
  BLOCK_SIZE
+ GLOBAL_MEMORY

HNSW — 18 → 19 fields

  <common header × 10>
  BLOCK_SIZE, M, EF_CONSTRUCTION, EF_RUNTIME, MAX_LEVEL, ENTRYPOINT,
  EPSILON, NUMBER_OF_MARKED_DELETED
+ GLOBAL_MEMORY

SVS (non-tiered) — 25 → 27 fields

  <common header × 10>
  BLOCK_SIZE, QUANT_BITS, ALPHA, GRAPH_MAX_DEGREE, CONSTRUCTION_WINDOW_SIZE,
  MAX_CANDIDATE_POOL_SIZE, PRUNE_TO, USE_SEARCH_HISTORY, NUM_THREADS,
  LAST_RESERVED_NUM_THREADS, NUMBER_OF_MARKED_DELETED, SEARCH_WINDOW_SIZE,
  SEARCH_BUFFER_CAPACITY, LEANVEC_DIMENSION, EPSILON
+ SHARED_SVS_THREADPOOL_MEMORY
+ GLOBAL_MEMORY

Tiered HNSW — 16 → 17 fields

  <common header × 10>           (ALGORITHM = "TIERED")
  MANAGEMENT_LAYER_MEMORY, BACKGROUND_INDEXING, TIERED_BUFFER_LIMIT
  FRONTEND_INDEX = nested [<FLAT fields, 11>]      (no GLOBAL_MEMORY in nested)
  BACKEND_INDEX  = nested [<HNSW fields, 18>]      (no GLOBAL_MEMORY in nested)
  TIERED_HNSW_SWAP_JOBS_THRESHOLD
+ GLOBAL_MEMORY

Tiered SVS — 17 → 18 fields

  <common header × 10>           (ALGORITHM = "TIERED")
  MANAGEMENT_LAYER_MEMORY, BACKGROUND_INDEXING, TIERED_BUFFER_LIMIT
  FRONTEND_INDEX = nested [<FLAT fields, 11>]
- BACKEND_INDEX  = nested [<SVS fields, 25>]
+ BACKEND_INDEX  = nested [<SVS fields, 26 — incl. SHARED_SVS_THREADPOOL_MEMORY>]
  TIERED_SVS_TRAINING_THRESHOLD, TIERED_SVS_UPDATE_THRESHOLD,
  TIERED_SVS_THREADS_RESERVE_TIMEOUT
+ GLOBAL_MEMORY

Two emission rules

1. GLOBAL_MEMORY is appended exactly once, at the outermost iterator level, by the C API wrapper. Never appears inside a nested FRONTEND_INDEX/BACKEND_INDEX.
2. SHARED_SVS_THREADPOOL_MEMORY is appended at the end of any SVS algorithm section by SVSIndex::debugInfoIterator(). So it shows up at the top level of a non-tiered SVS response, or inside BACKEND_INDEX of a tiered SVS response — never duplicated.

---

Stats / API output change

VecSim_GetGlobalMemory()

Before: API did not exist. The pool's slot vector and per-slot ThreadSlot objects went through the default allocator and were not tracked anywhere.

After:

size_t bytes = VecSim_GetGlobalMemory();
// == VecSimSVSThreadPool::getSharedAllocationSize()
//    (slot vector + per-slot ThreadSlot objects, allocated through the
//     dedicated VecSimAllocator).
// == 0 before any SVS index has been constructed and the worker pool size set.

Per-index getAllocationSize() (SVS only)

Before: Did not include any per-index portion of the parallelism slot, since the pool was untracked entirely.

After: Each SVS index's per-index allocator now tracks its own parallelism slot (a small fixed-size structure inside the index, allocated through the index's VecSimAllocator). The shared pool itself remains process-wide and reported via VecSim_GetGlobalMemory().

Cross-field invariant

Since the SVS thread pool is currently the only contributor to global memory:

VecSim_GetGlobalMemory() == VecSimSVSThreadPool::getSharedAllocationSize()
                         == <SHARED_SVS_THREADPOOL_MEMORY value in any SVS section>
                         == <GLOBAL_MEMORY value in any top-level VECSIM_INFO response>

This invariant is enforced by the new gtest SVSTest.debugInfoGlobalMemoryEqualsSharedSVSThreadPoolMemory. If a future contributor is added to VecSim_GetGlobalMemory() without updating breakdowns, the test will catch the drift.

---

Tests

• Added SVSTest.debugInfoGlobalMemoryEqualsSharedSVSThreadPoolMemory — asserts both new fields exist exactly once in a non-tiered SVS response and report the same bytes as VecSim_GetGlobalMemory().
• Updated compareFlatIndexInfoToIterator, compareHNSWIndexInfoToIterator, compareSVSIndexInfoToIterator to take an expect_global_memory parameter (default true) — needed because these comparators are called both with the C API iterator (top level, has GLOBAL_MEMORY) and as nested-backend comparators inside compareTieredIndexInfoToIterator (no GLOBAL_MEMORY).
• Bumped expected field counts: SVS 25 → 26, TIERED_SVS updated accordingly. FLAT/HNSW/TIERED_HNSW field-count constants represent the C++ method count (no GLOBAL_MEMORY); the comparators add +1 when called with the C API iterator.
• getSVSFields() / getTieredSVSFields() updated to reflect the new field positions.

---

Compatibility

• Wire-compatible — adds new fields at well-defined positions in VECSIM_INFO. Existing consumers parsing by field name are unaffected; consumers indexing by position must shift their expectations accordingly (covered above).
• Source-compatible — VecSim_GetGlobalMemory() is purely additive.
• Behavioral parity — for callers that don't read the new fields/API, total tracked memory is now strictly larger by exactly the bytes the shared SVS thread pool was already consuming but not reporting.

Mark if applicable

• This PR introduces API changes
• This PR introduces serialization changes

---

Note

Medium Risk
Adds a new public API and changes VECSIM_INFO/debug iterator output field counts/order, which can affect downstream consumers that rely on positional parsing or memory accounting. Core search/indexing logic is unchanged, but the thread-pool allocation tracking and singleton initialization checks could impact stats reporting if incorrect.

Overview
Adds process-wide VecSim memory reporting by tracking allocations of the shared SVS thread pool through a dedicated VecSimAllocator and exposing it via new VecSim_GetGlobalMemory().

VecSimIndex_DebugInfoIterator now appends a top-level GLOBAL_MEMORY field for all algorithms, while SVS debug info adds SHARED_SVS_THREADPOOL_MEMORY to report the pool’s bytes (and adjusts iterator capacity/count expectations accordingly). SVS index construction and size estimation were updated to account for per-index VecSimSVSThreadPool parallelism allocation, and unit tests/utilities were updated to validate the new fields and revised field counts.

^{Reviewed by Cursor Bugbot for commit 31c0e0a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0ce994f. Configure here.}

[codecov]

Codecov Report

❌ Patch coverage is 95.65217% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.97%. Comparing base (d2563bf) to head (31c0e0a).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/VecSim/algorithms/svs/svs_utils.h	92.30%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #967      +/-   ##
==========================================
+ Coverage   96.95%   96.97%   +0.01%     
==========================================
  Files         130      130              
  Lines        7749     7829      +80     
==========================================
+ Hits         7513     7592      +79     
- Misses        236      237       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.