> - why an empty "dtrace" module?

This is preliminary. I am thinking about dynamic probes, something like "logging" module but using dtrace. Still experimenting, not sure is actually possible.

Martin V Löwis suggested to use "sys.flags".

Undecided yet.

> - I'm worried that you're adding lots of delicate code inside
> critical core functions. Perhaps most of it can be factored out in
> separate functions living in another (dtrace-specific) C file? I
> don't think we really want to maintain some asm("nop") in the GC
> module, and I'm not even talking about the madness in ceval.c.

ceval.c madness is greatly reduced in the last version. I was not happy with it either. I am open to suggestions...

The point of DTrace probes is its very low overhead. If I change macros to external function calls, your performance will be suffer.

That said, I am open to suggestions, more understandable code, etc.

> - instead of generating code data (line numbers etc.) up front, why
> not generate and cache it lazily? that way, it would only be
> generated when the probes are really used (IIUC)

This case is special. This data is used by the kernel, when a DTrace script does a "jstack()". At this moment you can not CALL anything. You don't even have loops or "if".

Example: your program seems hangup, aparently. You can write a single line DTrace script to dump the jstack and see what your program is doing, even if it stuck in, let say, a function call. At this moment you can't call ANYTHING. So I precalculate the line offsets at import time, and use the table here. There is little else I can do, in kernel context.

> For higher-level benchmarks, I suggest you take a look at
> http://hg.python.org/benchmarks/

Good suggestions. I will check it.