suspect-devices/circuitpython/py/gc.c, branch v1.8.1CircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=v1.8.12016-05-12T21:16:38+00:00py/gc: gc_dump_alloc_table(): Dump heap offset instead of actual address.2016-05-12T21:16:38+00:00Paul Sokolovskypfalcon@users.sourceforge.net2016-05-12T21:16:38+00:00urn: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).
gc: gc_dump_alloc_table(): Use '=' char for tail blocks.2016-05-12T21:16:38+00:00Paul Sokolovskypfalcon@users.sourceforge.net2016-05-12T21:16:38+00:00urn:sha1:9a8751b006231bcc311c2d2c079f6cb7c8d2405e
'=' is pretty natural character for tail, and gives less dense picture
where it's easier to see what object types are actually there.
py/gc: Make (byte)array type dumping conditional on these types being enabled.2016-05-11T16:21:53+00:00Paul Sokolovskypfalcon@users.sourceforge.net2016-05-11T16:21:53+00:00urn:sha1:bc04dc277ed5c0dd1cce6e91bb713288ceeb4ff2py/gc: gc_dump_alloc_table(): Show byte/str and (byte)array objects.2016-05-11T16:00:15+00:00Paul Sokolovskypfalcon@users.sourceforge.net2016-05-11T15:52:46+00:00urn:sha1:3d7f3f00e03ef165aebef68a5f9710631494654b
These are typical consumers of large chunks of memory, so it's useful to
see at least their number (how much memory isn't clearly shown, as the data
for these objects is allocated elsewhere).
py/gc: Improve mark/sweep debug output.2015-12-27T18:40:36+00:00Paul Sokolovskypfalcon@users.sourceforge.net2015-12-27T17:50:34+00:00urn:sha1:3ea03a118880c9ffb6714049c0907a94b39d31a8
Previously, mark operation weren't logged at all, while it's quite useful
to see cascade of marks in case of over-marking (and in other cases too).
Previously, sweep was logged for each block of object in memory, but that
doesn't make much sense and just lead to longer output, harder to parse
by a human. Instead, log sweep only once per object. This is similar to
other memory manager operations, e.g. an object is allocated, then freed.
Or object is allocated, then marked, otherwise swept (one log entry per
operation, with the same memory address in each case).
py/gc: When printing info, use %u instead of UINT_FMT for size_t args.2015-12-18T12:52:45+00:00Damien Georgedamien.p.george@gmail.com2015-12-18T12:52:45+00:00urn:sha1:acaccb37ecae4e29c1e3e6fcd67c4b59bf39dfbd
Ideally we'd use %zu for size_t args, but that's unlikely to be supported
by all runtimes, and we would then need to implement it in mp_printf.
So simplest and most portable option is to use %u and cast the argument
to uint(=unsigned int).
Note: reason for the change is that UINT_FMT can be %llu (size suitable
for mp_uint_t) which is wider than size_t and prints incorrect results.
py/gc: Use size_t instead of mp_uint_t to count things related to heap.2015-12-17T01:09:11+00:00Damien Georgedamien.p.george@gmail.com2015-12-17T01:09:11+00:00urn:sha1:d977d268e848c1005d9105ebb6d789fb31b06c03
size_t is the correct type to use to count things related to the size of
the address space. Using size_t (instead of mp_uint_t) is important for
the efficiency of ports that configure mp_uint_t to larger than the
machine word size.
py/gc: For finaliser, interpret a pointer into the heap as concrete obj.2015-12-17T00:45:42+00:00Damien Georgedamien.p.george@gmail.com2015-12-17T00:45:42+00:00urn:sha1:f7782f8082b692611b5fa0bea4f7fbda8b433a7bpy/gc: Scan GC blocks as an array of pointers, not an array of objects.2015-12-17T00:41:37+00:00Damien Georgedamien.p.george@gmail.com2015-12-17T00:41:37+00:00urn:sha1:969e4bbe6a1660a1220f5f8781a252591b379cd2
The GC should search for pointers within the heap. This patch makes a
difference when an object is larger than a pointer (eg 64-bit NaN
boxing).
py/gc: Make GC block size be configurable.2015-12-02T23:40:52+00:00Paul Sokolovskypfalcon@users.sourceforge.net2015-12-02T23:40:52+00:00urn:sha1:75feece208fbf48c27099a4279cefcef42de4751