suspect-devices/circuitpython/py/gc.c, branch 0.8.3 CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=0.8.3 2016-11-29T22:11:32+00:00 Revert "py: Add ability to manually mark blocks during collect." 2016-11-29T22:11:32+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2016-11-29T22:11:32+00:00 urn:sha1:05c14dfe7809d4ac17c1e18b6ade8786212fc79f This reverts commit 93218281588b42331d83e4aaa45ac1abe4af130b. Add heap analysis scripts based on GDB breakpoint logs. 2016-11-24T01:31:53+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2016-11-24T01:31:53+00:00 urn:sha1:a8fbad5d8bfd6c0abca8a6759785c61d1f553b3f This introduces an alternative hardware API called nativeio structured around different functions that are typically accelerated by native hardware. Its not meant to reflect the structure of the hardware. 2016-11-21T22:11:52+00:00 Scott Shawcroft scott@chickadee.tech 2016-11-03T22:50:59+00:00 urn:sha1:ccbb5e84f980e252f7380d96fcc5c417a8a64523 Docs are here: http://tannewt-micropython.readthedocs.io/en/microcontroller/ It differs from upstream's machine in the following ways: * Python API is identical across ports due to code structure. (Lives in shared-bindings) * Focuses on abstracting common functionality (AnalogIn) and not representing structure (ADC). * Documentation lives with code making it easy to ensure they match. * Pin is split into references (board.D13 and microcontroller.pin.PA17) and functionality (DigitalInOut). * All nativeio classes claim underlying hardware resources when inited on construction, support Context Managers (aka with statements) and have deinit methods which release the claimed hardware. * All constructors take pin references rather than peripheral ids. Its up to the implementation to find hardware or throw and exception. py: Add ability to manually mark blocks during collect. 2016-11-21T22:11:49+00:00 Scott Shawcroft scott.shawcroft@gmail.com 2016-11-21T20:17:47+00:00 urn:sha1:93218281588b42331d83e4aaa45ac1abe4af130b py/gc: Add MICROPY_GC_CONSERVATIVE_CLEAR option to always zero memory. 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. py/gc: Implement GC running by allocation threshold. 2016-07-20T21:37:30+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-07-20T21:37:30+00:00 urn:sha1:93e353e3844f7116088a1a105ba588cade0e6783 Currently, MicroPython runs GC when it could not allocate a block of memory, which happens when heap is exhausted. However, that policy can't work well with "inifinity" heaps, e.g. backed by a virtual memory - there will be a lot of swap thrashing long before VM will be exhausted. Instead, in such cases "allocation threshold" policy is used: a GC is run after some number of allocations have been made. Details vary, for example, number or total amount of allocations can be used, threshold may be self-adjusting based on GC outcome, etc. This change implements a simple variant of such policy for MicroPython. Amount of allocated memory so far is used for threshold, to make it useful to typical finite-size, and small, heaps as used with MicroPython ports. And such GC policy is indeed useful for such types of heaps too, as it allows to better control fragmentation. For example, if a threshold is set to half size of heap, then for an application which usually makes big number of small allocations, that will (try to) keep half of heap memory in a nice defragmented state for an occasional large allocation. For an application which doesn't exhibit such behavior, there won't be any visible effects, except for GC running more frequently, which however may affect performance. To address this, the GC threshold is configurable, and by default is off so far. It's configured with gc.threshold(amount_in_bytes) call (can be queries without an argument). py/gc: Calculate (and report) maximum contiguous free block size. 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). py/gc: Be sure to count last allocated block at heap end in stats. 2016-06-30T09:56:21+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-06-29T22:59:24+00:00 urn:sha1:6a6e0b7e05c430239c67efb702c44359e044c25d Previously, if there was chain of allocated blocks ending with the last block of heap, it wasn't included in number of 1/2-block or max block size stats. py: Don't use gc or qstr mutex when the GIL is enabled. 2016-06-28T10:28:50+00:00 Damien George damien.p.george@gmail.com 2016-05-26T10:53:34+00:00 urn:sha1:a1c93a62b1d1020c5ef3ce1744469a118433d0e5 There is no need since the GIL already makes gc and qstr operations atomic. py/gc: Fix GC+thread bug where ptr gets lost because it's not computed. 2016-06-28T10:28:49+00:00 Damien George damien.p.george@gmail.com 2016-05-05T10:25:08+00:00 urn:sha1:3653f5144a9ad719f70e2d310e218cf724afc822 GC_EXIT() can cause a pending thread (waiting on the mutex) to be scheduled right away. This other thread may trigger a garbage collection. If the pointer to the newly-allocated block (allocated by the original thread) is not computed before the switch (so it's just left as a block number) then the block will be wrongly reclaimed. This patch makes sure the pointer is computed before allowing any thread switch to occur.