Stop the world when invalidating function versions
The tier1 interpreter specializes `CALL` instructions based on the values
of certain function attributes (e.g. `__code__`, `__defaults__`). The tier1
interpreter uses function versions to verify that the attributes of a function
during execution of a specialization match those seen during specialization.
A function's version is initialized in `MAKE_FUNCTION` and is invalidated when
any of the critical function attributes are changed. The tier1 interpreter stores
the function version in the inline cache during specialization. A guard is used by
the specialized instruction to verify that the version of the function on the operand
stack matches the cached version (and therefore has all of the expected attributes).
It is assumed that once the guard passes, all attributes will remain unchanged
while executing the rest of the specialized instruction.
Stopping the world when invalidating function versions ensures that all critical
function attributes will remain unchanged after the function version guard passes
in free-threaded builds. It's important to note that this is only true if the remainder
of the specialized instruction does not enter and exit a stop-the-world point.
We will stop the world the first time any of the following function attributes
are mutated:
- defaults
- vectorcall
- kwdefaults
- closure
- code
This should happen rarely and only happens once per function, so the performance
impact on majority of code should be minimal.
Additionally, refactor the API for manipulating function versions to more clearly
match the stated semantics.
If the PYTHON_BASIC_REPL environment variable is set, the site module
no longer imports the _pyrepl module.
Moreover, the site module now respects -E and -I command line
options: ignore PYTHON_BASIC_REPL in this case.
Spotted by @ngnpope.
`isatty` returns False to indicate the file is not a TTY. The C
implementation of _io does that (`Py_RETURN_FALSE`) but I got the
bool backwards in the _pyio implementaiton.
Run them with different locales and different date and time.
Add the @run_with_locales() decorator to run the test with multiple
locales.
Improve the run_with_locale() context manager/decorator -- it now
catches only expected exceptions and reports the test as skipped if no
appropriate locale is available.
- move the Py_Main documentation from the very high level API section
to the initialization and finalization section
- make it clear that it encapsulates a full Py_Initialize/Finalize
cycle of its own
- point out that exactly which settings will be read and applied
correctly when Py_Main is called after a separate runtime
initialization call is version dependent
- be explicit that Py_IsInitialized can be called prior to
initialization
- actually test that Py_IsInitialized can be called prior to
initialization
- flush stdout in the embedding tests that run code so it appears
in the expected order when running with "-vv"
- make "-vv" on the subinterpreter embedding tests less spammy
---------
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
The function now sets temporarily the LC_CTYPE locale to the locale
of the category that determines the requested value if the locales are
different and the resulting string is non-ASCII.
This temporary change affects other threads.
The term "free variable" has unfortunately become genuinely
ambiguous over the years (presumably due to the names of
some relevant code object instance attributes).
While we can't eliminate that ambiguity at this late date, we can
at least alert people to the potential ambiguity by describing
both the formal meaning of the term and the common
alternative use as a direct synonym for "closure variable".
---------
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Increase currently inadequate vertical spacing for the IDLE browsers (path,
module, and stack) on high-resolution monitors.
---------
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
gh-120762: make_ssl_certs: Don't set extensions for the CSR
`openssl req` fails with openssl 3.2.2 because the config line
authorityKeyIdentifier = keyid:always,issuer:always
is not supported for certificate signing requests (since the issuing
certificate authority is not known).
David von Oheimb, the OpenSSL dev that made the change, commented in:
https://github.com/openssl/openssl/issues/22966#issuecomment-1858396738 :
> This problem did not show up in older OpenSSL versions because of a bug:
> the `req` app ignored the `-extensions` option unless `-x505` is given,
> which I fixed in https://github.com/openssl/openssl/pull/16865.
(I assume `-x505` is a typo for `-x509`.)
In our `make_cert_key` function:
If `sign` is true:
- We don't pass `-x509` to `req`, so in this case it should be safe to
omit the `-extensions` argument. (Old OpenSSL ignores it, new OpenSSL
fails on it.)
- The extensions are passed to the `ca` call later in the function.
There they take effect, and `authorityKeyIdentifier` is valid.
If `sign` is false, this commit has no effect except rearranging the
CLI arguments.
* Spill the evaluation around escaping calls in the generated interpreter and JIT.
* The code generator tracks live, cached values so they can be saved to memory when needed.
* Spills the stack pointer around escaping calls, so that the exact stack is visible to the cycle GC.
This allows direct intersphinx references to APIs via references
like `` :func:`importlib.metadata.version` ``.
---------
Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) <wk.cvs.github@sydorenko.org.ua>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
* gh-117151: increase default buffer size of shutil.copyfileobj() to 256k.
it was set to 16k in the 1990s.
it was raised to 64k in 2019. the discussion at the time mentioned another 5% improvement by raising to 128k and settled for a very conservative setting.
it's 2024 now, I think it should be revisited to match modern hardware. I am measuring 0-15% performance improvement when raising to 256k on various types of disk. there is no downside as far as I can tell.
this function is only intended for sequential copy of full files (or file like objects). it's the typical use case that benefits from larger operations.
for reference, I came across this function while trying to profile pip that is using it to copy files when installing python packages.
* add news
---------
Co-authored-by: rmorotti <romain.morotti@man.com>
Kumar Aditya
Victor Stinner
mpage
monkeyman192
Kirill Podoprigora
Mikhail Efimov
Jan Kaliszewski
Cody Maloney
Bénédikt Tran
Serhiy Storchaka
Alyssa Coghlan
Ned Batchelder
Emily Morehouse
Zhikang Yan
ffelixg
sobolevn
Mark Shannon
Adam Turner
Petr Viktorin
Sergey B Kirpichev
Andrés Delfino
Tomas R.
Shantanu
Rigel Di Scala
Donghee Na
Tian Gao
morotti
Irit Katriel
isaacjones99
Nice Zombies
Felix Fontein