Restore _GUARD_KEYS_VERSION in LOAD_ATTR specializations - #130
Conversation
The 3.14 and 3.15 interpreters were missing the shared-keys version check in LOAD_ATTR_NONDESCRIPTOR_WITH_VALUES and LOAD_ATTR_METHOD_WITH_VALUES, so a warmed load site kept returning the cached class attribute after an instance stored the attribute through the type's shared keys. This is what breaks SQLAlchemy's deferred column loads in facebookincubatorgh-115. The restored blocks match what CPython's case generator emits for these opcodes on 3.14, and the cache entry they read is already populated: specialize_attr_loadclassattr writes the keys version whenever META_PYTHON is not defined.
| ) | ||
|
|
||
|
|
||
| class LoadAttrKeysVersionTests(unittest.TestCase): |
There was a problem hiding this comment.
Same feedback as #129, put this in test_jit_specialization.py and drop the cinderx.init().
|
Oh, this is interesting, and is going to need some changes to how we build things internally too. We end up generating the generated_cases.c.h from Meta Python 3.14 https://github.com/facebookincubator/cinder/tree/meta/3.14 where we've backported the upstream support for not needing the guards keys version. In addition to the backout here we'll need to update our internal syncing scripts too. Or maybe what's easier would be to update cinder-bytecodes.c to have the _GUARD_KEYS_VERSION inlined into the opcode and if it ifdef'd under META_PYTHON. |
@ddorian If you'd like to land the full fix for it I think we just need to add: |
Can you do the syncing and I rebase on top of it? |
Meta Python invalidates the type version when shared keys change, so _GUARD_TYPE_VERSION covers it there; check dk_version under #ifndef META_PYTHON. Move the regression tests into test_jit_specialization.py.
partial fix for #115