gh-108488: Initialize JUMP_BACKWARD cache to 0, not 17 (#108591)

This mis-initialization caused the executor optimization to kick in sooner than intended. It also set the lower 4 bits of the counter to `1` -- those bits are supposed to be reserved (the actual counter is in the upper 12 bits).

Author: gvanrossum

Lib/test/test_capi/test_misc.py

@@ -2478,7 +2478,7 @@ def testfunc(a):
 
         opt = _testinternalcapi.get_uop_optimizer()
         with temporary_optimizer(opt):
-            testfunc([1, 2, 3])
+            testfunc(range(10))
 
         ex = get_first_executor(testfunc)
         self.assertIsNotNone(ex)
@@ -2493,7 +2493,7 @@ def testfunc(a):
 
         opt = _testinternalcapi.get_uop_optimizer()
         with temporary_optimizer(opt):
-            testfunc([1, 2, 3])
+            testfunc(range(10))
 
         ex = get_first_executor(testfunc)
         self.assertIsNotNone(ex)

Misc/NEWS.d/next/Core and Builtins/2023-08-28-22-22-15.gh-issue-108488.e8-fxg.rst

@@ -0,0 +1 @@
+Change the initialization of inline cache entries so that the cache entry for ``JUMP_BACKWARD`` is initialized to zero, instead of the ``adaptive_counter_warmup()`` value used for all other instructions. This counter, unique among instructions, counts up from zero.

Python/specialize.c

@@ -302,7 +302,9 @@ _PyCode_Quicken(PyCodeObject *code)
         assert(opcode < MIN_INSTRUMENTED_OPCODE);
         int caches = _PyOpcode_Caches[opcode];
         if (caches) {
-            instructions[i + 1].cache = adaptive_counter_warmup();
+            // JUMP_BACKWARD counter counts up from 0 until it is > backedge_threshold
+            instructions[i + 1].cache =
+                opcode == JUMP_BACKWARD ? 0 : adaptive_counter_warmup();
             i += caches;
         }
     }