suspect-devices/circuitpython/py/gc.h, branch 5.3.xCircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=5.3.x2020-01-13T04:32:51+00:00fix CCCD bonding store; avoid excessive bonding writes2020-01-13T04:32:51+00:00Dan Halberthalbert@halwitz.org2020-01-13T04:32:51+00:00urn:sha1:9e7f8743c2725c1818033e348e8d542ec7539045* only make objects long lived if they are on the GC heap2019-11-22T18:47:13+00:00David Grimesdgrimes@navisite.com2019-11-22T18:47:13+00:00urn:sha1:f13ba7e8d9048802e960b45264f7d85cc16a1a4dInclude display objects in gc.2019-06-06T21:49:32+00:00Dan Halberthalbert@halwitz.org2019-06-06T21:49:32+00:00urn:sha1:62de2506e47c14a71c7a9fe04360697ccb966aebReorganize board busses into shared-bindings and shared-module.2019-04-08T23:58:50+00:00Scott Shawcroftscott@tannewt.org2019-04-08T23:58:50+00:00urn:sha1:0f003ac5b8312fafb120e86e05eefd2431014d8cEnter safe mode when an allocation is attempted on an uninitialized heap.2019-03-12T18:18:26+00:00Scott Shawcroftscott@tannewt.org2019-03-08T23:29:14+00:00urn:sha1:03be42ab847f04a89d207d98fdb28048cfedf72dWIP: after merge; before testing2018-07-11T20:45:30+00:00Dan Halberthalbert@halwitz.org2018-07-11T20:45:30+00:00urn:sha1:7c219600a246d8956d0b23ea3f5d125a820e6b6apy/gc: Add gc_sweep_all() function to run all remaining finalisers.2018-06-12T01:55:29+00:00Damien Georgedamien.p.george@gmail.com2018-05-31T13:10:48+00:00urn:sha1:522ea80f06a80fd799bd57de351373ceaeeae325
This patch adds the gc_sweep_all() function which does a garbage collection
without tracing any root pointers, so frees all the memory, and most
importantly runs any remaining finalisers.
This helps primarily for soft reset: it will close any open files, any open
sockets, and help to get the system back to a clean state upon soft reset.
Introduce a long lived section of the heap.2018-01-24T18:33:46+00:00Scott Shawcroftscott.shawcroft@gmail.com2018-01-24T00:22:05+00:00urn:sha1:416abe33ed44e44d8f75342731080217e123278b
This adapts the allocation process to start from either end of the heap
when searching for free space. The default behavior is identical to the
existing behavior where it starts with the lowest block and looks higher.
Now it can also look from the highest block and lower depending on the
long_lived parameter to gc_alloc. As the heap fills, the two sections may
overlap. When they overlap, a collect may be triggered in order to keep
the long lived section compact. However, free space is always eligable
for each type of allocation.
By starting from either of the end of the heap we have ability to separate
short lived objects from long lived ones. This separation reduces heap
fragmentation because long lived objects are easy to densely pack.
Most objects are short lived initially but may be made long lived when
they are referenced by a type or module. This involves copying the
memory and then letting the collect phase free the old portion.
QSTR pools and chunks are always long lived because they are never freed.
The reallocation, collection and free processes are largely unchanged. They
simply also maintain an index to the highest free block as well as the lowest.
These indices are used to speed up the allocation search until the next collect.
In practice, this change may slightly slow down import statements with the
benefit that memory is much less fragmented afterwards. For example, a test
import into a 20k heap that leaves ~6k free previously had the largest
continuous free space of ~400 bytes. After this change, the largest continuous
free space is over 3400 bytes.
all: Use the name MicroPython consistently in comments2017-07-31T08:35:40+00:00Alexander Steffendevel.20.webmeister@spamgourmet.com2017-06-30T07:22:17+00:00urn:sha1:55f33240f3d7051d4213629e92437a36f1fac50e
There were several different spellings of MicroPython present in comments,
when there should be only one.
all: Unify header guard usage.2017-07-18T01:57:39+00:00Alexander Steffendevel.20.webmeister@spamgourmet.com2017-06-29T21:14:58+00:00urn:sha1:299bc625864b9e624ed599c94a5f95870516139a
The code conventions suggest using header guards, but do not define how
those should look like and instead point to existing files. However, not
all existing files follow the same scheme, sometimes omitting header guards
altogether, sometimes using non-standard names, making it easy to
accidentally pick a "wrong" example.
This commit ensures that all header files of the MicroPython project (that
were not simply copied from somewhere else) follow the same pattern, that
was already present in the majority of files, especially in the py folder.
The rules are as follows.
Naming convention:
* start with the words MICROPY_INCLUDED
* contain the full path to the file
* replace special characters with _
In addition, there are no empty lines before #ifndef, between #ifndef and
one empty line before #endif. #endif is followed by a comment containing
the name of the guard macro.
py/grammar.h cannot use header guards by design, since it has to be
included multiple times in a single C file. Several other files also do not
need header guards as they are only used internally and guaranteed to be
included only once:
* MICROPY_MPHALPORT_H
* mpconfigboard.h
* mpconfigport.h
* mpthreadport.h
* pin_defs_*.h
* qstrdefs*.h