René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Executors might ignore instrumentation.","articleBody":"# Bug report\n\nCode handed to the optimizer may not include instrumentation. If instrumentation is added later, the executor does not see it.\nWe remove all `ENTER_EXECUTORS` when instrumenting, but that doesn't fix the problem of executors that are still running.\n\n### Example\n\nA loop that calls `foo`:\n```Py\nwhile large_number \u003e 0:\n    foo()\n    large_number -= 1\n```\nThe loop gets turned into an executor, and sometime before `large_number` reaches zero, a debugger gets attached and in some callee of `foo` turns on monitoring of calls. We would expect all subsequent calls to `foo()` to be monitored, but they will not be, as the executor knows nothing about the call to `foo()` being instrumented.\n\n### Let's not rely on the executor/optimizer to handle this.\n\nWe could add a complex de-optimization strategy, so that executors are invalidated when instrumentation occurs, but that is the sort of thing we want to be doing for maximum performance, not for correctness.\n\nIt is much safer, and ultimately no slower (once we implement fancy de-optimization) to add extra checks for instrumentation, so that unoptimized traces are correct.\n\n### The solution\n\nThe solution is quite simple, add a check for instrumentation after every call.\n\nWe can make this less slow (and less simple) by combining the eval-breaker check and instrumentation check into one. This makes the check slightly more complex, but should speed up `RESUME` by less than it slows down every call as every call already has an eval-breaker check.\n\nCombining the two checks reducing the number of bits for versions from 64 to 24 (we need the other bits for eval-breaker, gc, async exceptions, etc). A 64 bit number never overflows (computers don't last long enough), but 24 bit numbers do.\n\nThis will have three main effects, beyond the hopefully very small performance impact for all code:\n* It removes the need for a complete call stack scan of all threads when instrumenting. \n* Tools that set or change monitoring many times will see significant performance improvements as we no longer need to traverse all stacks to re-instrument the whole call stack whenever monitoring changes\n* Tools that set or change monitoring many millions of times will break, as we run out of versions. It is likely that these tools were already broken or had performance so bad as to be totally unusable.\n\n#### Making the check explicit in the bytecode.\n\nWe can simplify all the call instructions by removing the `CHECK_EVAL_BREAKER` check at the end and adding an explicit `RESUME` instruction after every `CALL`\n\nAlthough this has the disadvantage of making the bytecode larger and adding dispatch overhead, it does have the following advantages:\n* Allows tier 1 to optimize the `RESUME` to `RESUME_CHECK` which might be cancel out the additional dispatch overhead.\n* Makes the check explicit, making it feasible for tier 2 optimizations to remove it.\n\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-109846\n* gh-110358\n* gh-110384\n* gh-111642\n* gh-111657\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/markshannon","@type":"Person","name":"markshannon"},"datePublished":"2023-09-13T09:28:41.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/109369/cpython/issues/109369"}