| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
| |
of a boolean expression (#124394)
|
|
|
|
|
|
| |
Use a `_PyStackRef` and defer the reference to `f_funcobj` when
possible. This avoids some reference count contention in the common case
of executing the same code object from multiple threads concurrently in
the free-threaded build.
|
| |
|
|
|
| |
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
|
| |
|
|
|
| |
move up _PyType_IS_GC and use it
|
| |
|
|
|
|
|
|
|
|
|
| |
Lower the C recursion limit for HPPA, PPC64 and SPARC, as they use
relatively large stack frames that cause e.g. `test_descr` to hit
a stack overflow. According to quick testing, it seems that values
around 8000 are max for HPPA and PPC64 (ELFv1 ABI) and 7000 for SPARC64.
To keep things safe, let's use 5000 for PPC64 and 4000 for SPARC.
Co-authored-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
(GH-124163)
|
|
|
|
| |
Change also the fix for pycore_gc.h and pycore_stackref.h:
declare constants as uintptr_t, rather than casting constants.
|
| |
|
|
|
|
| |
of compiler (#123972)
|
|
|
|
| |
_PyCompile_IsInteractive (#124061)
|
|
|
|
| |
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Co-authored-by: Sam Gross <655866+colesbury@users.noreply.github.com>
|
|
|
|
| |
``PyTypeObject.tp_vectorcall`` using the ``PyType_FromSpec`` function family. (#123332)
|
| |
|
|
|
|
|
|
|
| |
(#124023)
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
(#123924)
Use a `_PyStackRef` and defer the reference to `f_executable` when
possible. This avoids some reference count contention in the common case
of executing the same code object from multiple threads concurrently in
the free-threaded build.
|
|
|
|
|
|
| |
constructing AST nodes (#123883)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In gh-121602, I applied a fix to a builtin types initialization bug.
That fix made sense in the context of some broader future changes,
but introduced a little bit of extra complexity. That fix has turned
out to be incomplete for some of the builtin types we haven't
been testing. I found that out while improving the tests.
A while back, @markshannon suggested a simpler fix that doesn't
have that problem, which I've already applied to 3.12 and 3.13.
I'm switching to that here. Given the potential long-term
benefits of the more complex (but still incomplete) approach,
I'll circle back to it in the future, particularly after I've improved
the tests so no corner cases slip through the cracks.
(This is effectively a "forward-port" of 716c677 from 3.13.)
|
| |
|
|
|
| |
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
| |
|
|
|
| |
Add Doc/c-api/config.rst documentation.
|
|
|
|
|
|
|
|
|
|
|
| |
Add PyConfig_Get(), PyConfig_GetInt(), PyConfig_Set() and
PyConfig_Names() functions to get and set the current runtime Python
configuration.
Add visibility and "sys spec" to config and preconfig specifications.
_PyConfig_AsDict() now converts PyConfig.xoptions as a dictionary.
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
|
|
|
|
|
|
| |
Switch more _Py_IsImmortal(...) assertions to _Py_IsImmortalLoose(...)
The remaining calls to _Py_IsImmortal are in free-threaded-only code,
initialization of core objects, tests, and guards that fall back to
code that works with mortal objects.
|
|
|
|
| |
Use _Py_IsImmortalLoose() in bytesobject.c, typeobject.c
and ceval.c.
|
| |
|
|
|
|
| |
* Replace _PyBytes_Join() with PyBytes_Join().
* Keep _PyBytes_Join() as an alias to PyBytes_Join().
|
| |
|
|
|
|
|
| |
Use 64-bit integers instead of platform specific size_t or Py_ssize_t
to represent the number of bits in Python integer.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add new functions to convert C <stdint.h> numbers from/to Python int:
* PyLong_FromInt32()
* PyLong_FromUInt32()
* PyLong_FromInt64()
* PyLong_FromUInt64()
* PyLong_AsInt32()
* PyLong_AsUInt32()
* PyLong_AsInt64()
* PyLong_AsUInt64()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `zip_next` function uses a common optimization technique for methods
that generate tuples. The iterator maintains an internal reference to
the returned tuple. When the method is called again, it checks if the
internal tuple's reference count is 1. If so, the tuple can be reused.
However, this approach is not safe under the free-threading build:
after checking the reference count, another thread may perform the same
check and also reuse the tuple. This can result in a double decref on
the items of the replaced tuple and a double incref (memory leak) on
the items of the tuple being set.
This adds a function, `_PyObject_IsUniquelyReferenced` that
encapsulates the stricter logic necessary for the free-threaded build:
the internal tuple must be owned by the current thread, have a local
refcount of one, and a shared refcount of zero.
|
|
|
|
| |
tier 2. (GH-123381)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
`Py_DECREF` and `PyStackRef_CLOSE` are now implemented as macros in the
free-threaded build in ceval.c. There are two motivations;
* MSVC has problems inlining functions in ceval.c in the PGO build.
* We will want to mark escaping calls in order to spill the stack
pointer in ceval.c and we will want to do this around `_Py_Dealloc`
(or `_Py_MergeZeroLocalRefcount` or `_Py_DecRefShared`), not around
the entire `Py_DECREF` or `PyStackRef_CLOSE` call.
|
| |
|
|
|
|
|
| |
(GH-123222)
Only count an instruction as deferred if hasn't deopted first.
|
| |
|
| |
|
|
|
|
|
| |
* Convert CALL_ALLOC_AND_ENTER_INIT to micro-ops such that tier 2 supports it
* Allow inexact arguments for CALL_ALLOC_AND_ENTER_INIT.
|
|
|
|
| |
GCC 11 and newer warn about the access to `unique_id` in non-debug builds
due to inlining the call on static non-heap types.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The free-threaded GC now visits interpreter stacks to keep objects
that use deferred reference counting alive.
Interpreter frames are zero initialized in the free-threaded GC so
that the GC doesn't see garbage data. This is a temporary measure
until stack spilling around escaping calls is implemented.
Co-authored-by: Ken Jin <kenjin@python.org>
|
| |
|
| |
|