You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we mostly spill the stack (saving it to memory) and save the stack pointer (saving to frame->stackpointer) but not always.
Calls to Py_DECREF, PyStackRef_CLOSE and related functions can escape (calling arbitrary Python code and causing the GC to run), but we do not spill the stack across these "call"s.
Spilling the stack across all escaping calls is a bit of a challenge, adding a fair bit of additional complexity to the code generators.
But it is worth it as it allows means that the GC is guaranteed to be able to see every reference on the stack(s). This means that we do not need to make conservative approximations about what references are live in a frame, nor do we need to NULL out unused stack values.
It also allows us to defer many, many more references than we currently do.
The content you are editing has changed. Please copy your edits and refresh the page.
Currently we mostly spill the stack (saving it to memory) and save the stack pointer (saving to frame->stackpointer) but not always.
Calls to
Py_DECREF
,PyStackRef_CLOSE
and related functions can escape (calling arbitrary Python code and causing the GC to run), but we do not spill the stack across these "call"s.Spilling the stack across all escaping calls is a bit of a challenge, adding a fair bit of additional complexity to the code generators.
But it is worth it as it allows means that the GC is guaranteed to be able to see every reference on the stack(s). This means that we do not need to make conservative approximations about what references are live in a frame, nor do we need to
NULL
out unused stack values.It also allows us to defer many, many more references than we currently do.
Tasks
The text was updated successfully, but these errors were encountered: