[WIP] gh-123358: Update LOAD_DEREF to use stackref and atomic incref

[corona10]

• Issue: Concurrent reads from cell objects (LOAD_DEREF) do not scale well #123358

[corona10]

@Fidget-Spinner I am still working on :) I will ping you once I am ready!

[corona10]

@colesbury Let's extract the utility function with separated PRs.

[corona10]

@Fidget-Spinner
Ken, Would you like to take a look at overall approach for both stack effect and stackref side?

I am not sure that I do correctly so before checking why Windows free-threaded is failed, I would like to get rough review.
Thank you for understanding.

[Fidget-Spinner]

This is a little suspicious. Why do we need the atomics when there's the critical section?

[corona10]

Let me check,, yeah we may don't need this.

[corona10]

SUMMARY: ThreadSanitizer: data race /home/runner/work/cpython/cpython/./Include/internal/pycore_cell.h:23:18 in PyCell_SwapTakeRef

Maybe TSAN thought that they could be memory ordering issue.

@colesbury, Do you think that this would be false alarm?

[colesbury]

We need the second atomic write here (to cell->ob_ref), but not the first one. In other words, something like:

old_value = cell->ob_ref;
FT_ATOMIC_STORE_PTR_RELEASE(cell->ob_ref, value);

Although the write happens in the critical section, the read happens (with this PR) outside of the lock. This is the same pattern we use in dictionaries :

cpython/Objects/dictobject.c

Lines 278 to 279 in da5855e

	#define STORE_KEY(ep, key) FT_ATOMIC_STORE_PTR_RELEASE(ep->me_key, key)
	#define STORE_VALUE(ep, value) FT_ATOMIC_STORE_PTR_RELEASE(ep->me_value, value)

[corona10]

I suspect that there would be a deadlock issue at the Windows build. I am under investigation.
But before that, I would like to know there is any wrong code about stack effect and stack ref.

[Fidget-Spinner]

But before that, I would like to know there is any wrong code about stack effect and stack ref.

Don't think so.

[corona10]

@colesbury found that there is a possible issue from

cpython/Lib/test/lock_tests.py

Lines 117 to 121 in 5e7eba0

	def wait_phase(self, phase, expected):
	for _ in support.sleeping_retry(support.SHORT_TIMEOUT):
	if len(phase) >= expected:
	break
	self.assertEqual(len(phase), expected)

which cause this TSAN error. We should fix it with a separate PR.