[native] Remove the libc++ dependencies from the CoreCLR host's timing

[simonrozsival]

Part of #12533 (drop libc++ from the CoreCLR host). Stacked on top of #12541.

Note: this PR is the combination of what were previously four stacked PRs, all of which modified timing-internal.hh (and three of them timing-internal.cc). Reviewed separately, the same two files had to be read in four different intermediate states; reviewed together, each libc++ dependency in the timing code is removed once. The sections below are in commit order, and the reference counts quoted in each are the counts at that point, so they step down as you read.

Why

The CoreCLR host's timing support is the last part of the host that reaches into libc++ for memory management, in two places:

• Timing::sequence_pool is a std::vector<managed_timing_sequence>, which pulls in operator new and __libcpp_verbose_abort (the vector's own length check).
• Host::_timing holds that Timing in a std::shared_ptr, which pulls in the whole __shared_weak_count family — atomic refcounting, the type-erased deleter and the control block destructor — none of which we need for an object that is created once and lives until the process exits.

Neither buys us anything here. The pool is a fixed-purpose allocator for a diagnostic feature, and the shared_ptr never shares: there is exactly one owner and no lifetime question to answer.

The constraint

Sequences are handed to managed code as an IntPtr and held across the TimingLogger.Start/Stop window, so every address handed out has to stay valid until the caller releases it. That is the requirement the container has to satisfy, and it rules out any contiguous growable array — reallocating to grow moves the elements, invalidating pointers already given out. Growability was never really the requirement; stable addresses are.

The fix

Allocate in chunks of 16 and chain them together:

struct sequence_chunk
{
    sequence_chunk           *next;
    managed_timing_sequence   sequences[SEQUENCE_CHUNK_SIZE];
};

get_available_sequence () scans the chunks for an entry that isn't in use and chains on a new one when it finds none. Chunks are never freed, so an address stays valid for the lifetime of the process, and entries are recycled through in_use exactly as the vector version did. Memory is bounded by peak concurrent usage rather than by total calls.

An intrusive free list would also work, and would be O(1) rather than a scan. It is deliberately not used: threading the recycling through the entries themselves makes a double release actively dangerous, because the entry lands on the list twice and is then handed to two callers at once, so release_sequence () would need a guard against it. Recycling through in_use keeps a double release a harmless redundant store, which is the behaviour today. This is diagnostic code and the scan is over at most a handful of entries, so there is nothing to gain by trading that away.

A chunk that cannot be allocated aborts, as elsewhere in the runtime, so get_available_sequence () never fails and no caller needs a null check.

Dropping the shared_ptr

With the vector gone, Timing is left with two constant-initialized members and needs no constructor, so it can be a plain static inline instance in BSS. That removes the allocation entirely, and with it the shared_ptr that owned it.

Host::_timing was then a pointer whose only remaining job was to encode "fast timing is disabled" as nullptr — a nullable pointer standing in for a boolean that FastTiming::enabled () already owns. So the pointer is gone too and get_timing () returns a Timing&; it cannot be const&, as get_available_sequence () and release_sequence () both mutate. Both P/Invokes in internal-pinvokes-clr.cc now gate on FastTiming::enabled () instead, which also removes an ordering assumption: previously enabled () could in principle be true before _timing had been assigned.

Note this only pays off on top of #12541. While sequence_lock was a std::mutex, its non-trivial destructor forced __cxa_atexit registration behind a guard variable, and making Timing a static was a net regression — measured at the time as +2 refs, trading one operator new for two __cxa_guard_*. Now that the lock is a pthread_mutex_t, the whole object is constant-initialized and the guard pair disappears as well.

Results

	refs	__cxa_guard_*
#12541 (base)	47	10
this PR	38	8

The nine removed, from diffing the demangled undefined-symbol sets of the two archives:

symbol	before	after
std::__ndk1::__shared_weak_count::__release_weak()	3	0
std::__ndk1::__shared_weak_count::~__shared_weak_count()	1	0
std::__ndk1::__shared_weak_count::__get_deleter(std::type_info const&) const	1	0
operator new(unsigned long)	4	3
std::__ndk1::__libcpp_verbose_abort(char const*, ...)	4	3
__cxa_guard_acquire	5	4
__cxa_guard_release	5	4

NativeAOT stays at 0.

Verification

• CoreCLR, MonoVM and NativeAOT all build clean
• The allocator was exercised standalone: 40 acquires → 40 distinct addresses in exactly 3 chunks; values written through the first 16 pointers are still readable after two further chunks are chained on; releasing all 40 and re-acquiring 40 allocates nothing new and draws entirely from the existing 48 slots; a triple release followed by two acquires still yields two distinct entries and no extra chunk
• MonoVM shares Timing and picks up the same change, with no edits under src/native/mono/

---

Also: FastTiming's event chunks

FastTiming::TimingEventChunk is a structurally identical chunked pool to the one introduced above — a fixed array of entries plus a next pointer, chained together and handed out as references that must stay valid for the lifetime of the process:

struct TimingEventChunk
{
    TimingEvent events [EVENT_CHUNK_SIZE];
    TimingEventChunk *next = nullptr;
};

It was still allocated with new/delete, so it gets the same calloc/free treatment for consistency. Zero-filling matches TimingEvent's default member initializers.

This does not move the reference count on its own, because the same translation units still reference operator new/operator delete for the std::string behind TimingEvent::more_info. Those are removed further down in this PR, and only then does the count actually drop — the metric is a per-file cliff, so only removing the last use of a symbol in an object counts.

---

Also: FastTiming::open_sequences

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 stack is only ever used through push, top, pop and empty, so a naive singly linked list is enough:

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 above, 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.

This removes the __cxa_thread_atexit category entirely (4 → 0).

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.

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.

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.

Together with the calloc change above, 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.

Also: replacing std::function with function pointers

std::function is a type-erasing wrapper: it has to be able to store, copy and destroy an arbitrary callable, and it pulls <functional> into every translation unit that sees the declaration. Neither of the two remaining uses in the CoreCLR host needs any of that.

FastTiming::dump

The line writer was taken by value:

void dump (size_t entries, bool indent, std::function<void(std::string_view const&)> line_writer) noexcept;

Of its two callers, dump_to_logcat passes a captureless lambda and dump_to_file captures a single FILE*. A plain function pointer plus an opaque context covers both:

using LineWriter = void (*) (FILE *output, std::string_view const& line);

void dump (size_t entries, bool indent, LineWriter line_writer, FILE *output) noexcept;

The context is typed as FILE* rather than void*, since the only caller that needs one writes to a file — that avoids a cast in the writer. dump_to_file passes its FILE* through instead of capturing it, and dump stays out of line — no template, so no code duplication per callback type.

The two writers are plain functions in an anonymous namespace rather than captureless lambdas. A lambda converted to a function pointer goes through a compiler generated static invoker, so using functions directly removes a level of indirection.

AssemblyStore::configure_from_payload

static void configure_from_payload (const void *payload_start, const std::function<std::string()>& get_full_store_path) noexcept;

The callback existed only to produce a store path for diagnostics, but the single caller was:

AssemblyStore::configure_from_payload (payload, [store_path]() -> std::string { return std::string { store_path }; });

That wraps a const char * in a std::string purely so that all three use sites can call .c_str () on it again. One of those three is the success-path log_debugf at the end of the function, so the callback runs on every startup and this allocated a string every time.

It now takes the const char * directly and uses the existing optional_string () helper, which also makes it null-safe. The stale comment describing the callback was updated — it claimed the path was only used for invalid payloads, which was not true.

Why the reference count does not move here

Both uses were fully inlined by the optimizer at -O2, so std::function's machinery was emitted into the objects rather than left as undefined references. What goes away is that generated machinery — 6,992 bytes come off libnet-android.release.so (546,904 → 539,912 B), plus one std::string allocation per startup.

Worth recording, since it is easy to misread as "no progress": llvm-nm --undefined-only lists each undefined symbol once per object file, so this metric counts (object, symbol) pairs rather than call sites. Measured per object across this change:

object	undefined symbol set	relocations	.text
host.cc.o	identical	60 → 56	30,550 → 30,026
assembly-store.cc.o	identical	84 → 83	24,424 → 24,106

The count only moves when the last use of a symbol in a given file goes away, so it behaves as a per-file cliff rather than a gradual measure.

The lambdas remaining inside dump are called directly instead of being converted to function pointers, so the optimizer already inlines them; replacing them with named functions measured 2 bytes larger, so they were left as they are.

Also: dropping <chrono>

FastTiming::get_time() has always read the clock with clock_gettime() directly — the comment above it even says we do that to avoid calling into libc++:

// We cheat a bit here, by avoiding a call to libc++ code that performs the same action.
// We can do it because we know our target platform.

std::chrono::steady_clock was then used only as the type tag of the chrono::time_point we wrapped the result in. So we were paying for <chrono> without using the clock it provides.

Timestamps are now a plain uint64_t nanosecond count, and <chrono> is removed from the four files that included it. In mainthread-dso-loader.hh the include was entirely unused.

Sharing the interval formatting

Four places repeated the same seconds / milliseconds / nanoseconds-within-the-millisecond split, so they now share one helper:

struct time_interval
{
	unsigned long long seconds;
	unsigned long long milliseconds;
	unsigned long long nanoseconds;

	explicit constexpr time_interval (time_point interval) noexcept
		: seconds { interval / NANOSECONDS_PER_SECOND },
		  milliseconds { interval / NANOSECONDS_PER_MILLISECOND },
		  nanoseconds { interval % NANOSECONDS_PER_MILLISECOND }
	{}
};

The split reproduces chrono::duration_cast exactly, including the fact that the middle field is the total milliseconds rather than a remainder. The timing output is byte-for-byte unchanged, which matters because the format after the first colon is parsed by our performance measuring utilities.

I verified this rather than assuming it: a standalone harness compared the old chrono computation against time_interval over the nine interesting edge cases (0, 999999, 1000000, 1000001, 999999999, 1000000000, …, INT64_MAX) plus 2,000,000 random values — 2,000,009 checked, 0 mismatches.

CLOCK_MONOTONIC_RAW → CLOCK_MONOTONIC

We now read CLOCK_MONOTONIC, the clock steady_clock is specified to use, instead of CLOCK_MONOTONIC_RAW. The two differ only in that CLOCK_MONOTONIC is slewed by NTP, which is irrelevant at the granularity we measure.

<chrono> is header-only, so this removes no undefined symbols; it takes a further 80 B off libnet-android.release.so and removes one more libc++ header from the build, which is a prerequisite for eventually building without libc++ headers at all.

Overall result

Across the whole PR, the CoreCLR undefined-libc++ reference count goes from 47 (at #12541) to 38 after the chunked pool, and the __cxa_thread_atexit and timing-related operator new/operator delete categories are eliminated entirely. NativeAOT stays at 0. src/native/mono/ is untouched throughout, though MonoVM shares Timing and picks up the same changes.

CoreCLR, MonoVM and NativeAOT all build clean.

[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.hh — ❌ error: get_available_sequence() returns nullptr on malloc failure, but the current callers…

What changed in this PR

This PR updates the native fast-timing implementation used by managed code to avoid handing out pointers into a growable std::vector buffer (which can reallocate and invalidate outstanding pointers). It replaces the sequence pool with a stable-address intrusive free list and updates the CoreCLR host to use a constant-lifetime Timing instance without heap allocation, supporting the broader effort to drop libc++ dependencies from the CoreCLR host.

Changes:

• Replace Timing::sequence_pool (std::vector) with an intrusive free list of individually malloc’d managed_timing_sequence nodes.
• Make the CoreCLR host timing singleton use a static inline instance (_timing_instance) and point _timing at it when enabled (no new Timing()).

File	Description
src/​native/​common/​include/​runtime-base/​timing.hh	Replaces vector-backed pool with free-list backed stable allocations for managed timing sequences.
src/​native/​clr/​include/​host/​host.hh	Introduces a static inline Timing instance to avoid heap allocation when timing is enabled.
src/​native/​clr/​host/​host.cc	Switches timing initialization from new Timing() to using the static instance.