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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

per-interpreter: memory allocators #30

Open
Tracked by #34
ericsnowcurrently opened this issue Aug 24, 2018 · 6 comments
Open
Tracked by #34

per-interpreter: memory allocators #30

ericsnowcurrently opened this issue Aug 24, 2018 · 6 comments
Labels
complexity: high very hard to figure out P1 medium priority size: large requires a lot of changes type: enhancement X [isolation] improved interpreter isolation X [runtime] CPython runtime (lifecycle, state)

Comments

@ericsnowcurrently
Copy link
Owner

ericsnowcurrently commented Aug 24, 2018

[maybe split into more granular tasks]

  1. move the global state back to Include/internal (see below)
  2. move PyRuntimeState.obj to PyInterpreterState.obj
  3. move PyRuntimeState.mem to PyInterpreterState.mem

Notable concerns:

  • very delicate code
  • allocators needed before main interpreter created (?)
  • keep a global allocator?

The global state for this was moved back out of Include/internal to fix a bug. That PR encapsulates the relevant global state and C-API pretty well.

@ericsnowcurrently ericsnowcurrently added X [isolation] improved interpreter isolation X [runtime] CPython runtime (lifecycle, state) P1 medium priority type: enhancement size: large requires a lot of changes complexity: high very hard to figure out labels Aug 24, 2018
@qizzzh
Copy link

qizzzh commented Jun 13, 2019

Can we have per interpreter heap and allocators and a flag telling whether we are in the main interpreter? The overhead doesn't sounds terrible.

@ericsnowcurrently
Copy link
Owner Author

"per interpreter allocators" is exactly what this issue is for.

What do you mean by "per interpreter heap"? The C heap wouldn't make sense so I'm guessing you're talking about the Python "heap". If so, that's pretty much unrelated to what we're working on here. Consider starting a thread on the python-ideas or python-dev mailing lists.

Where are you looking for a flag about the main interpreter? In the C code all the info is there already. From Python the information is exposed in PEP 554.

@vstinner
Copy link
Collaborator

A workaround is to disable pymalloc. It can even be done by setting PYTHONMALLOC env var to "malloc" for example. libc malloc() is thread safe.

@ericsnowcurrently
Copy link
Owner Author

@vstinner, a workaround for what? per-interpreter allocators or the bug for which we rolled back moving the allocators into PyRuntimeState?

@vstinner
Copy link
Collaborator

@ericsnowcurrently: "@vstinner, a workaround for what?"

pymalloc is not thread safe. If you want to experiment subinterpreters running in parallel in different threads, you can force the usage of the libc malloc()/free() by setting PYTHONMALLOC env var to "malloc".

@vstinner
Copy link
Collaborator

vstinner commented May 5, 2020

A workaround is to disable pymalloc. It can even be done by setting PYTHONMALLOC env var to "malloc" for example. libc malloc() is thread safe.

I proposed the following issue and PR to implement this workaround as a configure build option:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: high very hard to figure out P1 medium priority size: large requires a lot of changes type: enhancement X [isolation] improved interpreter isolation X [runtime] CPython runtime (lifecycle, state)
Projects
None yet
Development

No branches or pull requests

3 participants