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 C API and changes VECSIM_INFO/debug iterator field counts/order across all algorithms, which can break consumers that rely on positional parsing; also adjusts SVS thread-pool allocation paths affecting memory accounting.

Overview
Adds process-wide VecSim memory accounting by routing the shared SVS thread pool singleton allocations through a dedicated tracked VecSimAllocator, and by exposing the pool’s tracked bytes via the new public API VecSim_GetGlobalMemory().

Extends debug/info output: the C API VecSimIndex_DebugInfoIterator now appends a new top-level GLOBAL_MEMORY field for every index, while SVSIndex::debugInfoIterator() adds an SVS-specific SHARED_SVS_THREADPOOL_MEMORY field (including in tiered SVS via the backend iterator). Tests and debug-iterator field-count/order expectations are updated accordingly, and SVS thread-pool wrappers now require an allocator so per-index parallelism state is tracked.

^{Reviewed by Cursor Bugbot for commit 0ce994f. 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]

Tiered iterator missing GLOBAL_MEMORY handler causes test failure

Medium Severity

compareTieredIndexInfoToIterator asserts the field count as DebugInfoIteratorFieldCount::TIERED_SVS (18) and has no handler for GLOBAL_MEMORY_STRING in its while loop — any unrecognized field hits the else { FAIL(); } branch. If this function is ever called with an iterator produced by the C API VecSimIndex_DebugInfoIterator (which unconditionally appends GLOBAL_MEMORY), the assertion on number of fields will fail (19 != 18) and the field itself will trigger FAIL(). The comment at line 449 acknowledges this limitation but the function provides no expect_global_memory parameter like the other comparators do, leaving it fragile and inconsistent with compareFlatIndexInfoToIterator, compareHNSWIndexInfoToIterator, and compareSVSIndexInfoToIterator which all gained that parameter.

 

^{Reviewed by Cursor Bugbot for commit 94b40f8. Configure here.}

[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.}

[cursor]

SVS numberOfInfoFields reserve hint is incorrect

Low Severity

numberOfInfoFields is set to 24 but the method actually adds 26 fields (1 ALGORITHM + 9 common via addCommonInfoToIterator + 1 BLOCK_SIZE + 14 SVS-specific fields + 1 SHARED_SVS_THREADPOOL_MEMORY). The test constant DebugInfoIteratorFieldCount::SVS = 26 confirms the correct count. This value is used for reserve() so it causes an unnecessary vector reallocation rather than a crash, but the comment explicitly says "Update this number when needed" — and the PR added a field while setting it to an incorrect value.

 

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