What does this PR do?:

Stops StringDictionary from freeing or resetting buffer storage while a guarded accessor may still be using it.

• New RefCountGuard::tryWaitForRefCountsToClear(targets, n). It waits only for guards on the given resources and returns false on timeout instead of logging and returning normally.
• StringDictionary::clearAll() now returns [[nodiscard]] bool:
  • It waits only for guards on its own three buffers, so traffic on other dictionaries can neither delay nor fail the reset.
  • On timeout it changes nothing. There is no buffer clear, _next_id reset, counter reset or generation bump, and it returns false. A partial reset would be worse than none: restarting _next_id without clearing would reissue ids existing entries still use. A dictionary that wasn't reset stays consistent.
• clearStandby() now waits for guards on its target buffer and skips the clear on timeout. The skipped buffer becomes active on the next rotate() with its old entries. That's harmless because ids are only reassigned by clearAll(), and the buffer is cleared the next time it is the clear target.
• Profiler::start() logs a warning for any dictionary it could not reset. It only signals a ContextValueCache reset when the context-value map was actually reset.
• Removes waitForAllRefCountsToClear(), which no longer has callers.
• Updates doc/architecture/StringDictionary.md. It still described the _accepting recheck as removed, which it isn't, and claimed the arena made a stale read safe, which it doesn't: extra arena chunks and overflow nodes are freed.

Motivation:

PROF-16136. clearAll() disabled new accesses, called waitForAllRefCountsToClear() and then cleared all buffers unconditionally. On timeout (~500 ms) the drain only logged a warning, so a lookup that had already passed the _accepting recheck could resume into freed overflow SBTable nodes or arena chunks.

Two things made this more likely than the ticket describes:

• The drain was global. It needed one scan in which every guard slot in the process was empty. Profiler::start() resets three dictionaries back to back, and JNI callers (recordTraceRoot, registerConstant0, lookupClass) keep taking guards on the other two while one drains. So it could time out from churn alone, with no stalled thread. lookupClass() does not take _class_map_lock, so the class map is exposed too.
• The rotation path had the same bug one cycle later. rotate()'s waitForRefCountToClear(old_active) also proceeds on timeout in release builds. clearStandby() then cleared that buffer two rotations later with no drain at all.

Additional Notes:

• CallTraceStorage follows the same "free after a drain" pattern (processTraces(), clearTableOnly(), destructor), but it is latent there, not reachable. Every production caller of processTraces()/clear() holds lockAll(), every put() runs inside a stripe lock, and lockAll() waits without a time limit, so its drain cannot time out. The destructor never runs because the Profiler singleton is never deleted. A stacked PR documents that contract and hardens the timeout path.
• rotate() still uses waitForRefCountToClear, which aborts on timeout in debug builds. That is now a diagnostic only, since clearStandby() handles a straggler safely.
• A reset whose drain times out costs about 0.5–1 s in the new tests, longer under ASan. There is no test-only timeout override, to keep production code unchanged for tests.

How to test the change?:

New gtests:

• StringDictionaryReclamationTest.ClearAllKeepsStorageWhileGuardHeld and ClearStandbyKeepsBufferWhileGuardHeld. A helper thread holds a real RefCountGuard and a pointer to a key in a non-first arena chunk (memory clear() frees), then re-reads it after the reset.
  • Without the fix: in debug, the generation, buffer-size and id assertions fail. Under ASan, heap-use-after-free from StringArena::reset() ← clearAll() / clearStandby().
  • With the fix: passes in debug, ASan and TSan.
• StringDictionaryReclamationTest.ClearAllIgnoresGuardsOnOtherDictionaries: a guard on another dictionary neither fails nor delays the reset.
• RefCountGuardTryWaitTest.* (4 tests) for the new drain primitive.
• Existing callers (liveness/reference-chain tests, stress tests, fuzzer) now assert clearAll()'s result.

Results:

• gtest: gtestDebug (full suite) passes. ASan and TSan pass for stringDictionary_ut and refCountGuard_ut, and compileFuzzer succeeds.
• testDebug (Java): 224 tests, 1 failure: VirtualThreadWallClockTest.samplesCarrierFramesFromBlockingVT[cstack=vmx] ("no carrier-thread frames", a continuation-unwind check unrelated to dictionaries). It passed when the class was rerun on its own.

For Datadog employees:

• If this PR touches code that signs or publishes builds or packages, or handles
  credentials of any kind, I've requested a security review (run the dd:platform-security-review
  skill, or file a request via the PSEC review form).
  bewaire also runs automatically on every PR.
• This PR doesn't touch any of that.
• JIRA: PROF-16136

🤖 Generated with Claude Code