Torn reads of GC statistics from external process via get_gc_stats

[sergey-miryanov]

Bug report

Bug description:

If an external tool sampling GC statistics does not pause the target process (and we designed get_gc_stats not to pause), it can read torn data under certain circumstances.

There are two distinct problems:

1. Weakly ordered platforms: The stores of ts_start and ts_stop may be reordered by the CPU/optimizer. We need to add memory barriers to mitigate this.

2. Large memcpy window: We are copying a sufficiently large memory region via memcpy. If two or more GC cycles occur during this copy, we can end up with inconsistent data spanning multiple GC states.

@maurycy has an idea to use a sequence counter for consistency checks — I think he should definitely give it a try.

cc @pablogsal

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-155811: Add a seqcount to gc_stats to prevent torn reads #155828
• [3.15] gh-155811: Add a seqcount to gc_stats to prevent torn reads (GH-155828) #158829

[sergey-miryanov]

I don't think we should retry more than once if the GC stats read is inconsistent. Complex retry logic should be handled by the external tools.

[maurycy]

@sergey-miryanov All good now? :)

[sergey-miryanov]

Since this is a bug fix, I think it should be backported.

I don't think we'll get this into 3.15.0, so I'm perfectly fine with waiting for 3.15.1.

cc @hugovk

[hugovk]

Yep, this can wait for .1

• Core team: very little will be merged into the 3.15 branch between now and 3.15.0 final. Docs improvements always welcome.

https://discuss.python.org/t/python-3-15-following-tradition-lets-have-a-surprise-rc3/109313