cshung commented on PR #19123: URL: https://github.com/apache/nuttx/pull/19123#issuecomment-4687101073
Thanks for the feedback on the performance concern. I wanted to share some context about the trade-offs here: **1. The behavior is opt-in (default=n)** This is the most important point. Users who don't enable this configuration pay **zero** overhead. Only users who need POSIX-correct signal handler behavior (like managed runtimes) choose to enable it, and they're choosing correctness over marginal performance. **2. The fast path is minimal overhead** The fast path check (comparing register values + a little math + branch) happens on every exception, but it's just ~10-20 cycles. For 99.99%+ of exceptions where SP is not modified, we branch back to the existing behavior with no copy overhead. **3. The slow path is vanishingly rare** The expensive copy only happens when an exception occurs **right inside a trampoline** (like interface dispatch with multi-level inheritance). JITted code, async/await, and coroutines are not trampolines. This is an extreme edge case. **4. Correctness vs performance trade-off** If managed runtime developers accept GC pause costs (which can be 10-100ms, orders of magnitude slower than my 10-20 cycle fast path), then accepting a small cost for correct signal handler behavior is reasonable. The OS is supposed to abstract hardware away - when hardware doesn't restore SP correctly, the OS must compensate. **5. POSIX expectation** POSIX `sigaltstack()` allows signal handlers to use alternate stacks, and the implicit contract is that when a signal handler returns, the thread resumes with the context the handler established. Without this fix, SP changes are silently discarded, which breaks managed runtimes. Can you share actual measurements of how much slower? What's the baseline interrupt latency, and what percentage slower are you seeing? I'd like to understand the real impact. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
