suspect-devices/circuitpython/py/gc.c, branch v1.8.5 CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=v1.8.5 2016-08-26T05:35:26+00:00 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. py/gc: Fix 2 cases of concurrent access to ATB and FTB. 2016-06-28T10:28:49+00:00 Damien George damien.p.george@gmail.com 2016-05-04T09:14:43+00:00 urn:sha1:e33806aaff5787d57bd708f99e565f1c490fc069 py/gc: Make memory manager and garbage collector thread safe. 2016-06-28T10:28:49+00:00 Damien George damien.p.george@gmail.com 2016-04-25T15:28:57+00:00 urn:sha1:c93d9caa8b8be81f7e6faf9f2ca2ad16d4942ab8 By using a single, global mutex, all memory-related functions (alloc, free, realloc, collect, etc) are made thread safe. This means that only one thread can be in such a function at any one time. py: Add MP_STATE_THREAD to hold state specific to a given thread. 2016-06-28T10:09:31+00:00 Damien George damien.p.george@gmail.com 2016-04-22T22:44:56+00:00 urn:sha1:330165a2cc9a0d4d5d00f13f851412c25d5f4ed2 py/gc: gc_dump_alloc_table(): Dump heap offset instead of actual address. 2016-05-12T21:16:38+00:00 Paul Sokolovsky pfalcon@users.sourceforge.net 2016-05-12T21:16:38+00:00 urn:sha1:68a7a92cecdf24ad869fbe06138bbdd669015db3 Address printed was truncated anyway and in general confusing to outsider. A line which dumps it is still left in the source, commented, for peculiar cases when it may be needed (e.g. when running under debugger).