Making the memory manager more pluggable #1604
Conversation
…and fix for new realloc feature
…ed code to gc_basic, returned gc.c to it's original state
- Nothing seems to be able to test replacing gc_free with a NOOP
…gaurds and including
|
TODO: t has documentation stating the following:
I think I have a mechanism to cleanly break this appart, but I need to know if changing the |
It needs to stay as one whole. The idea is that we might in the future allow to pass around a single pointer which points to all the internal VM state, so that we can make it reentrant. This pointer would point to the mp_state_ctx, which then has in it all the other stuff, including memory manager state. |
|
OK, but will changing the gc struct break ASM code?
|
No. Changing mp_state_mem_t won't break the asm nlr code. |
9167980 to
1cc81ed
Compare
…ame-check-interrupts Don't wait for display frame if interrupt pending
|
Closing due to inactivity. See related effort in #3580. |
This is the pull request for making the memory manager more pluggable -- i.e. separate the gc from the heap manager to allow advancements on both separately.
This is part of the solution for #1168 and is a rework of several PR attempts:
This PR attempts to consolodate the advice from those failed PR's and make a change that is as minimally invasive as possible to the existing code base and meets the coding guidlelines as much as possible.
The pull request uses the existing infrastructure to allow each build to select which garbage collector implementation it wants, either the original or the "basic" as the pluggable versions are being called. Eventually more gc implementations will be added, the next planned one is one that simply uses unix's malloc/free.
In addition, an
astyle.fmtfile has been added to thetools/directory that should define a fair number of micropython's coding conventions so that new contributors can automatically get their code formatted correctly and painlessly. This file may be a work in progress.