gh-150411: fix gc_generation.count race

[LindaSummer]

Issue

gh-150411

Root Cause

Refer the analytics in issue gh-150411, it should be a gc_generation.count update during the cyclic object allocation triggered the local allocation count migrated to young generation. Meantime we try to read the gc_generation.count without sync caused the race.

cpython/Python/gc_free_threading.c

Lines 2017 to 2037 in c714b56

	staticvoid
	record_allocation(PyThreadState*tstate)
	{
	struct_gc_thread_state*gc=&((_PyThreadStateImpl*)tstate)->gc;
	// We buffer the allocation count to avoid the overhead of atomic
	// operations for every allocation.
	gc->alloc_count++;
	if (gc->alloc_count >= LOCAL_ALLOC_COUNT_THRESHOLD) {
	// TODO: Use Py_ssize_t for the generation count.
	GCState*gcstate=&tstate->interp->gc;
	_Py_atomic_add_int(&gcstate->young.count, (int)gc->alloc_count);
	gc->alloc_count=0;
	if (gc_should_collect(gcstate) &&
	!_Py_atomic_load_int_relaxed(&gcstate->collecting))
	{
	_Py_ScheduleGC(tstate);
	}
	}
	}

I find this problem during proposing gh-150356. So they have similar reproduce way.

Proposed Changes

I added an atomic relax load guard for the gc_generation.count.
It was protected in other places expect current one.

[pablogsal]

Same concerns as #150356 (comment)

CC @nascheme

[kumaraditya303]

Does gcstate->old[0].count need to be atomic here? I think it is only ever written under stw so it is unnecessary.

[LindaSummer]

Hi @kumaraditya303 ,

Thanks very much for your review! ❤️
Yes, I searched the usage of count and find that only the young.count is updated without STW guard.
old[generation].count are all protected by STW.
So we only need to make young.count use atomic action and old[generation].count read is safe.

[LindaSummer]

Hi @pablogsal and @kumaraditya303 ,

Thanks very much for your review and suggestions!

I have updated the patch with only atomic for young.count.
The old[generation].count write is protected by STW.
The young.count is a frequently updated counter and in this patch we only read its snapshot.
So I think the result is consistent since we only synced one variable.

Please correct me if I made any mistake or misunderstanding.

Wish you a good day! 🌞

[miss-islington-app]

Thanks @LindaSummer for the PR, and @kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @LindaSummer for the PR, and @kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15.
🐍🍒⛏🤖

[bedevere-app]

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

[bedevere-app]

GH-153788 is a backport of this pull request to the 3.15 branch.