From my perspective, we currently face two choices:
We completely remove DTrace and clean up the related documentation
We restore support to pre-3.12 levels
Regarding the reasons for removing DTrace support, @markshannon has provided some explanations in both Issue 104280 and PR 125019, roughly as follows:
We now have PEP 669 as low-cost tracing
If it can’t be compatible with JIT, it has limited value
From my personal sentiment and practical use case perspective, I hope to support DTrace for the following reasons:
From an engineering scenario standpoint, DTrace, PEP 669, and the Remote Debugging support coming in 3.15 differ significantly in principles and use cases. A common use case for DTrace is that specific users employ non-intrusive instrumentation to obtain audit and operational information. Additionally, people also use more general technology stacks like eBPF to assist in program monitoring: https://github.com/cloudflare/ebpf_exporter/blob/master/examples/usdt.bpf.c#L17-L27
Regarding JIT scenarios, please forgive my presumption. In the near future or medium-term timeframe, I believe widespread use of JIT in production environments won’t be commonplace. In this situation, people might choose to disable JIT to continue using CPython (this point was also mentioned in PR125019). In such cases, DTrace won’t become worthless; on the contrary, it will be extremely valuable in specific scenarios.
The interaction between DTrace and JIT is actually a solvable problem. However, I think we need to make a decision now: whether DTrace will continue to be maintained in the CPython codebase.
Official binaries for Python 3.14 will be released with JIT support. How useful will it be to add/restore support for a Unix profiling feature that will need to be removed in a couple of versions’ time, if it doesn’t support the JIT? I expect the pace of adoption will increase, especially as experimentation with it becomes easier.
More broadly, who will maintain support? DTrace requires special configure options, meaning it requires dedicated testing, as opposed to something like sys.monitoring.
Can we enable DTrace support conditional on the JIT not being enabled until we land full DTrace support with JIT? I understand and applaud the functionality provided by sys.monitoring but it handles a use case that is fundamentally distinct from that handled by DTrace.
I’m happy to contribute time and resourcing to ensure that this particular corner of Python becomes functional again.
I recently encountered the need described here while analyzing a complex code base. I’ve made this library which stitches the new-style sys.monitoring interfaces up to USDT, so that bpftrace can observe python and kernel activity simultaneously … hopefully its useful to others who arrive here
I originally added dtrace to Python 3.6 and I would like to restore the probes that we can restore. For 3.15 it’s feasible to restore function calls but not per-line execution. That seems to be the workable solution for us now.
Yes, but it seems the different core developer have different view on this. Do we need the DTrace or not? I think maybe we need to make a decision. The feature is totally different with docs since 3.12.. it’s too long I think
