Provide an "aggressive" specialization/JIT mode for debugging

[brandtbucher]

@markshannon recently pointed out that our thresholds for JIT stuff are high enough that running the test suite isn't quite the stress test that it used to be. While these thresholds will probably come down with time, it might make sense to provide a mode where specialization and the JIT happen much more aggressively, for development purposes.

Our current values are:

• ADAPTIVE_WARMUP_VALUE: 1 (specialize the 2nd time an instruction is run)
• ADAPTIVE_COOLDOWN_VALUE: 52 (re-specialize the 53rd time a guard fails)
• JUMP_BACKWARD_INITIAL_VALUE: 4095 (JIT a new "root" trace the 4096th time we jump backwards)
• SIDE_EXIT_INITIAL_VALUE: 4095 (JIT a new side-exit trace the 4096th time a guard fails)

I propose that this new mode use the following values:

• ADAPTIVE_WARMUP_VALUE: 1 (specialize the 2nd time an instruction is run)
• ADAPTIVE_COOLDOWN_VALUE: 1 (re-specialize the 2nd time a guard fails)
• JUMP_BACKWARD_INITIAL_VALUE: 15 (JIT a new "root" trace the 16th time we jump backwards)
• SIDE_EXIT_INITIAL_VALUE: 15 (JIT a new side-exit trace the 16th time a guard fails)

A few notes:

• Specializing the first time an instruction runs leads to weird situations (for example, STORE_ATTR can fail to specialize if storage for the new attribute doesn't exist yet), so it doesn't make sense to reduce ADAPTIVE_WARMUP_VALUE further.
• We fall into infinite loops if ADAPTIVE_COOLDOWN_VALUE is reduced to zero. This probably indicates a bug where we are specializing, then immediately deopting (because the specialization is incorrect somehow).
• 16 was chosen for the JIT thresholds so that branch counters have time to stabilize.
• We should probably make this a configure option, not a runtime-togglable value, since these counters are set and reset constantly using static inline functions and constant values, and we want to avoid introducing branching and indirection. Maybe it makes sense to just turn this on if configured --with-pydebug to keep things simple?

Before moving forward with this, we first need to update all tests that hardcode assumptions about these values (I already have a branch for this). This is worth doing anyways so the values can be tweaked in the future with minimal disruption.

Linked PRs

• GH-129386: Use symbolic constants for specialization tests #129415
• GH-129386: Add test.support.reset_code #129486

[encukou]

The PR broke a lot of Refleaks buildbots. @brandtbucher,can you fix it topay, or should we revert it for now?

[brandtbucher]

I can look at it today. Didn't see any failures posted to the PR though (and I'm surprised it's causing leaks).

[brandtbucher]

Thanks for the heads-up! I've opened a PR with a fix.

[brandtbucher]

After talking with @markshannon, what we probably want for this issue is to put all of these counters in one place to make them easier to tweak. A new mode isn't very flexible, and is quite a bit of work. So we'll start with reorganization and helpful comments.