Profile F# programs correctly: busy threads once per tick, arrays never located, honest truncation and error codes, fresh leak badges

[MelbourneDeveloper]

TLDR

Fixes the .NET profiler engine, aggregation, error-code and UI bugs that SharpLsp's new F# profiler suites exposed against real F# programs.

Details

CPU

• Idle samples counted as active (Symbolizer.cs, [PROF-DOTNET-CPU-SYMBOLS]).
  • IsManaged tested PayloadByName("Type") is int, but TraceLog returns ClrThreadSampleTraceData, whose Type is a ClrThreadSampleType enum. The test never matched, so every sample counted as managed.
  • Effect: a main thread waiting on stdin took about half of every profile, and idle WaitNative/Sleep/Read frames buried the hot F# functions.
  • Fix: match on { Type: ClrThreadSampleType.Managed }.
• Shared frames counted once per thread (aggregate.rs, [PROF-AGGREGATION-LOGIC]).
  • Lines and functions were deduplicated within one thread's stack. A frame every thread shares, such as the runtime's thread entry point, therefore counted once per thread, and its samples outnumbered the ticks.
  • Fix: lines, functions and self time now count once per tick across every thread's stack. Shares are measured against the ticks that kept a stack (busy_ticks).
  • The tests move to aggregate/tests.rs to keep the file under 500 lines.
• Wrong error for a named runtime on a busy PID (service.rs, [PROF-CPU-START] step 1).
  • cpu.start checked for an existing session before resolving the runtime. Naming a runtime that cannot profile a busy PID answered ALREADY_PROFILING instead of UNSUPPORTED_RUNTIME.

Memory

• Arrays anchored at their element's line (SourceLocator.cs, [PROF-DOTNET-SOURCE]).
  • TypeNames.Definition cut Order[] at its [, so the array was located wherever Order is constructed.
  • A ResizeArray<Order> keeps its backing array after Clear(), so that line stayed painted after the last Order died.
  • Fix: the new TypeNames.IsArray gives an array no location. The spec now states the rule.
• Truncated retention graph reported as complete (RetentionGraph.cs, [PROF-DOTNET-HEAP-MARK]).
  • refs keeps at most a quarter of the node budget as targets and drops every other instance, but it reported truncated only when the node cap was hit.
  • Fix: omitted instances now set truncated.
• Dead program reported as OTHER (memory.rs, memory/mod.rs, error.rs, [PROF-ERRORS]).
  • A memory step turned every engine failure into OTHER, so a snapshot of a program that had exited lost the engine's PROCESS_NOT_FOUND.
  • Fix: the new MemoryError::Attach { kind, .. } keeps the classified code.
• Stale leak badges (memory-decorations.ts).
  • applyLeakDecorations never cleared the previous diff's badges, and badges shared per-colour decoration types with the allocation track. As a result:
    • a LOW badge survived next to the following MEDIUM one;
    • a flat diff left every badge in place;
    • a LOW badge overwrote allocation paint of the same purple.
  • Fix: the allocation track and the badges are now separate MemoryLayers. A diff repaints only the badge layer; a snapshot clears both. One painter replaces two copies of the same loop.

How Do The Automated Tests Prove It Works?

lspkit tests

• dotnet_e2e and dotnet_fsharp_e2e › cpu_profiling_finds_*_hot_function_and_its_lines call assert_only_busy_threads_count. It asserts that the stdin-waiting entry point is never hot and that the hot function holds more than 50% of samples. Both failed before the Symbolizer fix.
• aggregate/tests.rs covers once-per-tick counting of a frame every thread shares.
• dotnet_e2e › a_named_runtime_is_resolved_before_the_pid_is_found_busy checks the start-order fix: UNSUPPORTED_RUNTIME even while a CPU session exists.
• dotnet_e2e › a_memory_step_on_an_exited_program_is_process_not_found checks the dead-program fix: -32001, never OTHER.
• error.rs › maps_every_failure_to_its_code covers the two new MemoryError::Attach cases.
• Local make ci: 397/397 tests pass. Coverage: lsp-profiler 92.05%, lsp-profiler-dotnet 91.96%.

SharpLsp suites, run against the real engine and FsOrderLedger, with no test changes:

• profiler-fsharp-memory-e2e went from 2 of 3 failing to 3/3 passing. The two failures were:
  • the Order line is no longer painted once no Order lives (1 !== 0);
  • a Medium badge: ○ LOW +70.3 KB leak (1000 objects).
• profiler-fsharp-retention-e2e: the Order, Quote, AuditEntry and OrderRejected graphs at depth 2 / 8 nodes now report truncated: true.
• Regression: the 11 older SharpLsp memory and profiler suites (151 tests) and this package's UI suite (157 tests) still pass.