Performance is neutral. If you squint, startup is slightly faster and JIT-heavy benchmarks are slightly slower, but it's mostly in the noise for this machine.

We chatted about that at PyCon but it sounded like it didn't really seem like the right trade-off because there's not a strong justification for having it in the first place.

Yeah, if we left it in we'd need to test it, etc. It's intended to be a lightweight workaround for JITs with self-modifying code on newer Macs that don't support WX pages, which doesn't apply to us. I think it's cleaner to just pull it out for now.

This supersedes #134292

@hugovk, @zanieb, @ned-deily: thoughts on backporting this change? I know we're in RC, but this would allow macOS distributors like uv to ship the JIT (like it does for other platforms) without carrying this patch. The new code is reverting things to the way they worked in 3.13 and part of 3.14 (and Linux) anyways, so I'm personally confident that backporting won't lead to issues.

thoughts on backporting this change?

I need to test the change first, which I'll do in the next day. But, assuming no problems, it should definitely be backported for 3.14. We've been handwaving about older release support while waiting for this to be fixed.

Fine by me when Ned gives the nod.

Should we try to get the backport into the next RC @ned-deily @hugovk?

Should we try to get the backport into the next RC @ned-deily @hugovk?

I'm looking at it now.

GH-137701 is a backport of this pull request to the 3.14 branch.

Looks good for main and for 3.14 as well. There was a minor conflict with backporting to 3.14 so I created a manual backport for it in #137701.

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot x86-64 MacOS Intel NoGIL 3.14 (tier-1) has failed when building commit 2392232.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/1679/builds/406) and take a look at the build logs.
4. Check if the failure is related to this commit (2392232) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/1679/builds/406

Failed tests:

• test_largefile
• test_tools
• test.test_concurrent_futures.test_process_pool

Failed subtests:

• test_force_shutdown_workers - test.test_concurrent_futures.test_process_pool.ProcessPoolSpawnProcessPoolExecutorTest.test_force_shutdown_workers

Summary of the results of the build (if available):

==

Traceback (most recent call last):
  File "/Users/ec2-user/buildbot/buildarea/3.14.itamaro-macos-intel-aws.nogil/build/Lib/test/test_concurrent_futures/util.py", line 71, in tearDown
    self.assertLess(dt, 300, "synchronization issue: test lasted too long")
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 352.783409319818 not less than 300 : synchronization issue: test lasted too long

Both 3.15 and 3.14 seem to be failing after this change:

https://buildbot.python.org/#/release_status

Is it a genuine failure? Or perhaps something up with the buildbot worker? cc @itamaro just in case.

I doubt it's due to this change, since NoGIL and the JIT can't even be built together.

The failing test name test_largefile seems suspicious, maybe the bot is low on disk/memory?

Back to green after second rebuild 👍

https://buildbot.python.org/#/builders/1679/builds/409