René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Ensuring good specialization while making progress in jitted code","articleBody":"### The problem\n\nFor obvious reasons, it is necessary that jitted code makes progress: it can't spin in an infinite loop making no progress.\nTo ensure this happens, we require that any executor attached to an `ENTER_EXECUTOR` instruction executes at least one instruction (opcode, not uop) before returning to the interpeter.\nThis means that the first instruction in a trace cannot exit, which prevents specialization.\nWorse, some unspecialized instructions, notably `CALL` and `SEND` cannot be jitted at all, due to complex control flow.\n\n#### Dropping the requirement for progress\n\nWe could drop the requirement for progress in exceutors and have `ENTER_EXECUTOR` handle it: if it appears that an executor has no made progress when returning to `ENTER_EXECUTOR` then do not dispatch normally to the next `ENTER_EXECUTOR` but dispatch to the underlying executor. @brandtbucher likes this approach.\n\nThere are a few issue with this approach, however:\n* It makes attaching traces to side exits more complicated, as we need to check that we aren't attaching a no-progress trace to a no-progress exit\n* It may prevent, or at least complicate, tail-calling from jitted code into the interpreter in future, as we will need to communicate that progress has been made\n* It complicates `ENTER_EXECUTOR`\n\n### A solution\n\nInstead of worrying about what happens when a trace starts with an instruction that needs to be specialized, or cannot be jitted, we can make sure that that situation never happens or, at least, happens very rarely.\n\nThere are three possible ways to start tracing, plus a fourth that we may add in the future\n1. At a backwards jump\n2. (In the future) at the start of a function\n3. After a guard failure; a side exit.\n4. At the end of another executor\n\nCases 1 and 2 are trivial, as they start with a non-specializable instruction, so progress is guaranteed.\nIf an executor makes progress, then we don't to make progress on side traces, so case 3 is not a problem either.\nIt is only case 4 that is causing trouble.\n\nIf we can only end traces at locations that aren't problematic, then we are guaranteed progress.\n\nTraces can end if we either run out of resources (trace too long, or too deep) or we hit an instruction that we can't handle in the JIT.\nWe can deal with the too long case by backing up to a known good ending point.\nWe can't do anything about hitting an instruction that can't be jitted, but we can reduce the number of such instructions so that we can jit through them and not end on specializable instructions.\n\n#### Instructions that cannot be handled in the JIT\n\nMany of these are monitoring and other rare instructions that we don't much care about.\nHowever there are the specializable instructions (families) that we do care about.\nFrom (old) stats it appears that `CALL` and `SEND` form the bulk of the cases where we stop tracing on a specializable instruction.\n\n### Tasks\n\n* Complete specialization for `CALL`, including adding \"generic specializations\"\n* Complete specialization for `SEND`, including adding \"generic specializations\"\n* Track last known good exit point during tracing/optimization and truncate overly long traces to that point\n\n#### Specializations for `CALL`\n\n1. Make sure that if more specific specializations for Python functions fail, we still specialize to `CALL_PY_GENERAL`\n2. Add `CALL___CALL___PY` for `__call__` implemented in Python, and `CALL___CALL___C` for `__call__` implemented in C as  the \"generic specializations\". We should still guard on the type, even though they are \"generic\".\n\n#### Specializations for `SEND`\n\nThe `SEND` instruction is used in `yield from` and `await`. \nWe already specialize for generators and coroutines in `yield from` and `await` respectively, but\nsequences like `list` and `tuple` are also common in `yield from`.\nAsync generators are also common, but that might just be our benchmarks.\n\nIt might be worth investigating the possibility of merging `FOR_ITER` and `SEND` to take advantage of the \nexisting specializations for sequences.\n\nAs a first step, however, we should add a non-generator, non-coroutine, \"generic specialization\" so that the JIT\ncan handle it.\n","author":{"url":"https://github.com/markshannon","@type":"Person","name":"markshannon"},"datePublished":"2026-02-20T17:42:37.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/145047/cpython/issues/145047"}