CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.0.0-alpha.0 2018-07-11T20:45:30+00:00 2018-07-11T20:45:30+00:00 Dan Halbert halbert@halwitz.org 2018-07-11T20:45:30+00:00 urn:sha1:7c219600a246d8956d0b23ea3f5d125a820e6b6a 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-12-20T05:55:42+00:00 Damien George damien.p.george@gmail.com 2017-12-20T05:54:31+00:00 urn:sha1:26d4a6fa45526fa7c267cd9228259642701708f6 m_malloc already checks for a failed allocation so there's no need to check for it in m_malloc0. 2017-12-07T16:01:40+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-12-07T15:57:33+00:00 urn:sha1:9ebc037eee575fd951dea92c82ed9704d9101924 This is mostly a workaround for forceful rebuilding of mpy-cross on every codebase change. If this file has debug logging enabled (by patching), mpy-cross build failed. 2017-12-07T08:52:40+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2017-12-07T08:52:40+00:00 urn:sha1:88a8043a27c3f75c7e4e52e4e8b0d47005cd6bef Error out if they're set incompatibly. 2017-08-31T07:00:14+00:00 Damien George damien.p.george@gmail.com 2017-08-31T07:00:14+00:00 urn:sha1:ca21aed0a11903db04fc96056f8a08e452aaf504 2017-08-15T01:53:36+00:00 Stefan Naumann me@stefannaumann.de 2017-07-24T16:55:14+00:00 urn:sha1:ace9fb54053c29574bdf81ffacc5ddcf9d4b45d9 It enables all the DEBUG_printf outputs in the py/ source code. 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. 2016-08-26T05:35:26+00:00 Damien George damien.p.george@gmail.com 2016-08-26T05:35:26+00:00 urn:sha1:5ffe1d8dc07930818bbac6a88bec2aa5bd973402 There can be stray pointers in memory blocks that are not properly zero'd after allocation. This patch adds a new config option to always zero all allocated memory (via gc_alloc and gc_realloc) and hence help to eliminate stray pointers. See issue #2195. 2016-02-23T13:53:38+00:00 Damien George damien.p.george@gmail.com 2016-02-23T13:53:38+00:00 urn:sha1:e9d1a94bf099d585d0f8d3b0dddb8e0a397afcff