CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=azure 2019-03-12T18:18:26+00:00 2019-03-12T18:18:26+00:00 Scott Shawcroft scott@tannewt.org 2019-03-08T23:29:14+00:00 urn:sha1:03be42ab847f04a89d207d98fdb28048cfedf72d 2018-07-11T20:45:30+00:00 Dan Halbert halbert@halwitz.org 2018-07-11T20:45:30+00:00 urn:sha1:7c219600a246d8956d0b23ea3f5d125a820e6b6a 2018-06-12T01:55:29+00:00 Damien George damien.p.george@gmail.com 2018-05-31T13:10:48+00:00 urn: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. 2018-01-24T18:33:46+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2018-01-24T00:22:05+00:00 urn: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. 2017-07-31T08:35:40+00:00 Alexander Steffen devel.20.webmeister@spamgourmet.com 2017-06-30T07:22:17+00:00 urn:sha1:55f33240f3d7051d4213629e92437a36f1fac50e There were several different spellings of MicroPython present in comments, when there should be only one. 2017-07-18T01:57:39+00:00 Alexander Steffen devel.20.webmeister@spamgourmet.com 2017-06-29T21:14:58+00:00 urn: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 2016-06-30T21:09:55+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-06-30T21:09:55+00:00 urn:sha1:749cbaca7f5406e23bbf0009477c73e14fa8a9ff Just as maximum allocated block size, it's reported in allocation units (not bytes). 2015-11-29T14:25:04+00:00 Damien George damien.p.george@gmail.com 2015-11-27T13:07:48+00:00 urn:sha1:94fe6e523d42ecc342c1f6a9734ed2edf232ddbd The GC works with concrete pointers and so the types should reflect this. 2015-11-07T14:26:11+00:00 Dave Hylands dhylands@gmail.com 2015-11-06T22:32:47+00:00 urn:sha1:7f3c0d1ea8fa21df3b2078c7189f2b26fe36da59 Currently, the only place that clears the bit is in gc_collect. So if a block with a finalizer is allocated, and subsequently freed, and then the block is reallocated with no finalizer then the bit remains set. This could also be fixed by having gc_alloc clear the bit, but I'm pretty sure that free is called way less than alloc, so doing it in free is more efficient. 2015-07-14T21:56:32+00:00 Damien George damien.p.george@gmail.com 2015-06-13T20:53:22+00:00 urn:sha1:ade9a052365247be5ed4ce8b53c2164a576a4a05 Previous to this patch all interned strings lived in their own malloc'd chunk. On average this wastes N/2 bytes per interned string, where N is the number-of-bytes for a quanta of the memory allocator (16 bytes on 32 bit archs). With this patch interned strings are concatenated into the same malloc'd chunk when possible. Such chunks are enlarged inplace when possible, and shrunk to fit when a new chunk is needed. RAM savings with this patch are highly varied, but should always show an improvement (unless only 3 or 4 strings are interned). New version typically uses about 70% of previous memory for the qstr data, and can lead to savings of around 10% of total memory footprint of a running script. Costs about 120 bytes code size on Thumb2 archs (depends on how many calls to gc_realloc are made).