[native] Remove the libc++ dependencies from FastTiming

[simonrozsival]

Part of #12533. Stacked on top of #12545.

The problem

FastTiming::open_sequences tracks the timing events which have been started but not yet ended on each thread:

static inline thread_local std::stack<TimingEvent*> open_sequences;

std::stack defaults to std::deque as its underlying container, and std::deque has both a non-trivial constructor and a non-trivial destructor. For a thread_local, that means every translation unit which includes timing-internal.hh emits a guarded dynamic initializer for it, plus a __cxa_thread_atexit registration so the deque is destroyed when the thread exits. timing-internal.hh is included by both the CoreCLR and the MonoVM hosts.

The change

The stack is only ever used through push, top, pop and empty, so a naive singly linked list is enough — no need for libc++ here:

struct OpenSequence
{
    TimingEvent *event;
    OpenSequence *next;
};

static inline thread_local OpenSequence *open_sequences = nullptr;

The head pointer is a plain pointer, so it is trivially destructible and constant initialized: no guard variable, and nothing to register with __cxa_thread_atexit. The list itself is unbounded — any number of events may be open at once, exactly as before.

Locking: open_sequences is thread_local, so the list is private to its thread and needs no lock. This change keeps it that way — no state moves into shared storage — so there is still nothing to synchronize.

Lifetime: nodes are freed as they are popped rather than being recycled. That matters here because, unlike the process-wide timing sequence pool in #12545, this list is per thread and threads come and go — recycling nodes would mean every thread that ever recorded a timing event left its nodes behind. A thread that balances its start_event and end_event calls now leaves nothing allocated when it exits. Allocation failure aborts, matching how the timing sequence chunks behave.

Results

Undefined libc++ references across the three archives the CoreCLR host links, libnet-android.release-static-release.a, libruntime-base-release.a and libruntime-base-common-release.a:

symbol	before	after
__cxa_thread_atexit	4	0
std::__ndk1::__libcpp_verbose_abort(char const*, ...)	5	4
total	64	59

This removes the __cxa_thread_atexit category entirely.

Verification

• CoreCLR and MonoVM both build clean (only the pre-existing format_managed_type_name warning).
• Symbol counts above measured with llvm-nm --undefined-only over all three archives, before and after, on the same build tree.
• The push/top/pop/empty semantics were checked against a standalone harness with instrumented malloc/free, covering the empty, balanced-LIFO, interleaved, over-pop and 100 000-deep cases, asserting strict LIFO order and that every node is freed. 20/20 pass.
• src/native/mono/ is untouched.

---

Also: the two std::strings the earlier timing pass missed

#12513 removed the local strings from the timing code, but two heap-allocated ones survived in FastTiming and were only spotted later while attributing the remaining libc++ references. They live in the same two files as the change above, so they are fixed here.

TimingEvent::more_info

std::string *more_info = nullptr;

It is always built from one or two std::string_views whose combined length is known up front, so it becomes a plain NUL-terminated char* produced by a single malloc plus one or two memcpys. If the allocation fails we drop the extra information for that one event rather than aborting — timing is a diagnostic facility and must not take the application down with it.

FastTiming::output_file_name

std::unique_ptr<std::string> output_file_name{};

The name is parsed out of the debug.mono.timing system property, whose entire value is capped at PROP_VALUE_MAX (92) bytes, so a fixed 128 byte buffer inside FastTiming is always large enough. Keeping it inline also keeps the global internal_timing instance constant-initialized, so it needs no guard variable. A name that does not fit is rejected with a warning and the default is used.

<memory> and <string> are no longer needed by timing-internal.hh at all.

Result

Together with the calloc commit added to #12545, this clears the last operator new/operator delete references from timing-internal.cc.o (2 → 0) and, as a side effect, from typemap.cc.o (2 → 0) — typemap.cc had been inheriting them purely from the inlined new TimingEventChunk in FastTiming::get_event.

At the tip of the stack the CoreCLR total goes from 26 to 22, and only two objects still reference libc++: host.cc.o (11) and assembly-store.cc.o (11).

[Copilot]

Copilot review overview

Review tier: Lite
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	src/​native/​common/​include/​runtime-base/​timing-internal.hh — Suggestion: the comment hard-codes an observed nesting depth ("currently 3"), which is likely to…

What changed in this PR

This PR reduces CoreCLR-host libc++/ABI surface area and startup overhead by replacing FastTiming’s thread_local std::stack (deque-backed, non-trivial TLS init/destroy) with a trivially-initialized fixed-capacity array plus a per-thread depth counter.

Changes:

• Replace thread_local std::stack<TimingEvent*> open_sequences with thread_local TimingEvent* open_sequences[MAX_OPEN_SEQUENCES] and thread_local size_t open_sequence_depth.
• Introduce push_sequence_event, get_sequence_event, and pop_sequence_event helpers and update start_event (and TLS warm-up) to use them.
• Add MAX_OPEN_SEQUENCES constant and associated documentation describing expected nesting constraints.

File	Description
src/​native/​common/​runtime-base/​timing-internal.cc	Switch TLS warm-up to the new fixed-array push/pop helpers.
src/​native/​common/​include/​runtime-base/​timing-internal.hh	Replace deque-backed TLS stack with trivially-initialized fixed array + depth; add helper methods and max-depth constant.

[simonrozsival]

Consolidated into #12545 to reduce the depth of the #12546 stack.

No code changed: the commits from this PR are now part of #12545 unmodified, and the resulting tree is byte-identical. This PR sat directly on top of #12545 and touched the same files, so reviewing them together is easier than reviewing the same file across two intermediate states.