Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe GC for free-threaded build in the GC design doc #1263

Merged
merged 3 commits into from
Feb 6, 2024

Conversation

colesbury
Copy link
Contributor

@colesbury colesbury commented Jan 24, 2024

This updates the garbage collector design page to describe the implementation of the GC for Python 3.13's free-threaded build.


馃摎 Documentation preview 馃摎: https://cpython-devguide--1263.org.readthedocs.build/

@colesbury
Copy link
Contributor Author

I think there's still some more I should add to the document, but I wanted to first get feedback on the general approach of mixing the descriptions of the two designs.

Comment on lines 56 to 60
CPython contains two GC implementations starting in version 3.13. One implementation
is used in the default build and relies on the global interpreter lock for
thread-safety. The other implementation is used in the free-threaded build. Both
implementations use the same basic algorithms, but operate on different data
structures.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could use a list to make the difference between the two builds stand out more, and to mirror the two sections below. Something like:

Suggested change
CPython contains two GC implementations starting in version 3.13. One implementation
is used in the default build and relies on the global interpreter lock for
thread-safety. The other implementation is used in the free-threaded build. Both
implementations use the same basic algorithms, but operate on different data
structures.
Starting in version 3.13, CPython contains two GC implementations starting in version 3.13:
* the default build implementation relies on the global interpreter lock for
thread-safety;
* the free-threaded build ...
Both implementations use the same basic algorithms, but operate on different data
structures.

Here you could also add link to :term:s like GC and GIL using intersphinx.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a section at the end to summarize the differences between the two implementations. I was hesitant to add it here because we introduce a number of the concepts later on in the document.

object -----> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| ob_tid | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| pad | ob_mutex | ob_gc_bits | ob_ref_local | |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do each --+ mark one bit? If so, ob_tid, ob_ref_shared and *ob_type are 2 bytes (16 bits), but this fields don't seem to match the description, since ob_gc_bits takes ~4 bits and ob_ref_local 6.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No -- each row is 64-bits (on 64-bit platforms), but otherwise the fields pad, ob_mutex, ob_gc_bits, and ob_ref_local are not to scale.

I'm not sure what to do about this. It'd be nice if the diagram were to scale, but I think that would require the diagram to be very wide -- ob_gc_bits is only 1 byte, but 10 characters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be enough to just add a note after the diagram saying that e.g. "Note that pad, ob_mutex, ob_gc_bits, and ob_ref_local are not to scale and take X, Y, Z, W bytes respectively."

Another option, if those 4 values are related, could be to use a single name (like "free-threaded info bytes") and then break that down afterwards, either in text or with a separate "zoomed in" diagram.

internals/garbage-collector.rst Outdated Show resolved Hide resolved
internals/garbage-collector.rst Outdated Show resolved Hide resolved
@ambv
Copy link
Contributor

ambv commented Feb 6, 2024

Let's get this in and iterate on the live document.

@ambv ambv merged commit fe3722d into python:main Feb 6, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants