-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Share global string identifiers in deepfreeze #90868
Comments
Since bpo-46541, the global strings are statically allocated so they can now be referenced by deep-frozen modules just like any other singleton. Sharing identifiers with deepfreeze will reduce the duplicated strings hence it would save space. |
I have refactored generate_global_objects.py, and now instead of hard-coding every identifier manually, it now scans *.c files extracts the identifiers used in it and then generate the header file. This has multiple advantages:
|
In bpo-47067, there was concern about the addition of the makefile target from PR 31637:
After a new
which fails with a compilation error because that identifier is not yet defined. Is there a good way to convince |
I'm looking into this. A temporary workaround is to run Tools/scripts/generate-global-objects.py directly. |
We do the following: * move the generated _PyUnicode_InitStaticStrings() to its own file * move the generated _PyStaticObjects_CheckRefcnt() to its own file * include pycore_global_objects.h in extension modules instead of pycore_runtime_init.h These changes help us avoid including things that aren't needed. #90868
Add _PyStaticObject_CheckRefcnt() function to make _PyStaticObjects_CheckRefcnt() shorter. Use _PyObject_ASSERT_FAILED_MSG() to log the object causing the fatal error.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: