Mirrors/cpython - cpython - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Pablo Galindo	17c4edc4e0	bpo-43693: Revert commits `2c1e2583fd` and `b2bf2bc1ec` (GH-26530) * Revert "bpo-43693: Compute deref offsets in compiler (gh-25152)" This reverts commit `b2bf2bc1ec`. * Revert "bpo-43693: Add new internal code objects fields: co_fastlocalnames and co_fastlocalkinds. (gh-26388)" This reverts commit `2c1e2583fd`. These two commits are breaking the refleak buildbots.	5 years ago
Eric Snow	2c1e2583fd	bpo-43693: Add new internal code objects fields: co_fastlocalnames and co_fastlocalkinds. (gh-26388) A number of places in the code base (notably ceval.c and frameobject.c) rely on mapping variable names to indices in the frame "locals plus" array (AKA fast locals), and thus opargs. Currently the compiler indirectly encodes that information on the code object as the tuples co_varnames, co_cellvars, and co_freevars. At runtime the dependent code must calculate the proper mapping from those, which isn't ideal and impacts performance-sensitive sections. This is something we can easily address in the compiler instead. This change addresses the situation by replacing internal use of co_varnames, etc. with a single combined tuple of names in locals-plus order, along with a minimal array mapping each to its kind (local vs. cell vs. free). These two new PyCodeObject fields, co_fastlocalnames and co_fastllocalkinds, are not exposed to Python code for now, but co_varnames, etc. are still available with the same values as before (though computed lazily). Aside from the (mild) performance impact, there are a number of other benefits: * there's now a clear, direct relationship between locals-plus and variables * code that relies on the locals-plus-to-name mapping is simpler * marshaled code objects are smaller and serialize/de-serialize faster Also note that we can take this approach further by expanding the possible values in co_fastlocalkinds to include specific argument types (e.g. positional-only, kwargs). Doing so would allow further speed-ups in _PyEval_MakeFrameVector(), which is where args get unpacked into the locals-plus array. It would also allow us to shrink marshaled code objects even further. https://bugs.python.org/issue43693	5 years ago
Eric Snow	9f494d4929	bpo-43693: Add _PyCode_New(). (gh-26375) This is an internal-only API that helps us manage the many values used to create a code object. https://bugs.python.org/issue43693	5 years ago
Mark Shannon	adcd220556	bpo-40222: "Zero cost" exception handling (GH-25729) "Zero cost" exception handling. * Uses a lookup table to determine how to handle exceptions. * Removes SETUP_FINALLY and POP_TOP block instructions, eliminating (most of) the runtime overhead of try statements. * Reduces the size of the frame object by about 60%.	5 years ago
Mark Shannon	c76da79b37	bpo-42739: Don't use sentinels to mark end of line table. (GH-25657) * Add length parameter to PyLineTable_InitAddressRange and doen't use sentinel values at end of table. Makes the line number table more robust. * Update PyCodeAddressRange to match PEP 626.	5 years ago
Neil Schemenauer	87ec26b812	bpo-43372: Use _freeze_importlib for regen-frozen. (GH-24759) This approach ensures the code matches the interpreter version. Previously, PYTHON_FOR_REGEN was used to generate the code, which might be wrong. The marshal format for code objects has changed with bpo-42246, commit `877df851`. Update the code and the expected code sizes in ctypes test_frozentable.	5 years ago
Neil Schemenauer	ffa55d21b4	bpo-39448: Add regen-frozen makefile target. (GH-18174) Add the "regen-frozen" makefile target that regenerates the code for the frozen __hello__ module.	5 years ago