Currently, the GC can be executed on every object allocation. This has been historically the source of many problems because it can trigger a GC run in points where the VM is in an inconsistent state. This includes critical points of the eval loop but also during complex object creation since the GC can run while creating sub-elements of the final result meanwhile the object is not fully initialized.
To improve the situation, we can schedule a GC run on object allocation but the GC will only run then on the eval breaker in a similar fashion we currently use to run signal handlers, do GIL switch and run pending callbacks.
The text was updated successfully, but these errors were encountered:
We can opportunistically check if the GC is scheduled to run and run it if we have a request in PyErr_CheckSignals. This can benefit native code that needs to call PyErr_CheckSignals if is going to run for some time without executing Python code to ensure signals are handled. Checking for the GC here allows long-running native code to clean cycles created using the C-API even if it doesn't run the evaluation loop
pablogsal commentedOct 5, 2022
Currently, the GC can be executed on every object allocation. This has been historically the source of many problems because it can trigger a GC run in points where the VM is in an inconsistent state. This includes critical points of the eval loop but also during complex object creation since the GC can run while creating sub-elements of the final result meanwhile the object is not fully initialized.
To improve the situation, we can schedule a GC run on object allocation but the GC will only run then on the eval breaker in a similar fashion we currently use to run signal handlers, do GIL switch and run pending callbacks.
The text was updated successfully, but these errors were encountered: