feat(prof): move allocation profiler stack collection to safe point

[realFlowControl]

Description

The allocation profiler currently collects a stack trace immediately when the sampling threshold (4MB) is reached. This can occur anywhere in the PHP VM, including outside safe points. While usually safe, there are rare cases where opline has been free()'d and not restored, leading to use-after-free issues during stack collection 💥

These are engine-level bugs, which we've addressed retroactively via upstream fixes and/or profiler-side workarounds. This PR takes a proactive approach by deferring stack trace collection until the next safe point, by storing allocation samples in TLS and raising the engine interrupt flag. At the next interrupt - where we already handle wall/CPU time sampling - we check for a pending allocation sample and collect the trace then.

Out of Scope / Follow-Up Work

1. Stack trace collection for I/O samples should also be deferred to safe points.
2. When multiple profiler events (e.g., wall time, CPU time, allocation) are pending, we should ideally collect only one stack trace to reduce overhead. This will require additional refactoring.
3. Investigate whether we can attach wall/CPU timing metrics to allocation samples when collected, potentially increasing resolution without introducing sampling bias.

Point 2 seems like a clear improvement, but due to its architectural implications, it's deferred for now. Importantly, this PR already avoids redundant stack walks in one case: when a single PHP function call performs multiple allocations and hits the sampling threshold multiple times, we previously performed multiple redundant stack walks. With this change, those are consolidated into a single stack trace collected at the next safe point.

Reviewer checklist

• Test coverage seems ok.
• Appropriate labels assigned.

[pr-commenter]

Benchmarks [ profiler ]

Benchmark execution time: 2025-06-25 16:00:22

Comparing candidate commit 657058f in PR branch florian/safe-point with baseline commit 0db0b0e in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 28 metrics, 8 unstable metrics.

[morrisonlevi]

This is fine for a proof of concept; it let's us see how the accuracy of the allocation profiler is impacted.

However, it will walk the stacks twice, which is wasteful. If you are trying to compare overhead, you'll want to fix that first, or disable wall time sampling when testing.

We should think carefully about this, but I think it may make sense to gather time any time we walk the stack.

[realFlowControl]

This is fine for a proof of concept; it let's us see how the accuracy of the allocation profiler is impacted.

That's the sole reason I opened a draft PR, that way I can see prof-correctness tests (as well as all other tests) and have a binary that I can ship.

However, it will walk the stacks twice, which is wasteful. If you are trying to compare overhead, you'll want to fix that first, or disable wall time sampling when testing.

Exactly, it is collecting two stack traces. This does not affect the outcome, but the overhead 😉

We should think carefully about this, but I think it may make sense to gather time any time we walk the stack.

I thought about that as well, as we have the stack trace already, we can easily add wall-/cpu-time to it. Let's measure once we are there.

[realFlowControl]

Even though we could fix it here, I'd say we are also save to ignore this for the time being, as only very very very few people are using ZTS PHP.