suspect-devices/circuitpython/py/malloc.c, branch v1.0.1CircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=v1.0.12014-05-03T22:27:38+00:00Add license header to (almost) all files.2014-05-03T22:27:38+00:00Damien Georgedamien.p.george@gmail.com2014-05-03T22:27:38+00:00urn:sha1:04b9147e150d2d6fa3750f312fe328b6a71c1b28
Blanket wide to all .c and .h files. Some files originating from ST are
difficult to deal with (license wise) so it was left out of those.
Also merged modpyb.h, modos.h, modstm.h and modtime.h in stmhal/.
py, gc: Only zero out the extra bytes at the end of the heap chunk.2014-04-26T21:23:42+00:00Damien Georgedamien.p.george@gmail.com2014-04-26T21:23:42+00:00urn:sha1:32bef315be8e56ad2d7f69223fe7b9606893b6ab
This is a small optimisation to zero out only the additional bytes that
the caller did not ask for.
py, gc: Zero out newly allocated blocks in the GC.2014-04-25T22:37:55+00:00Damien Georgedamien.p.george@gmail.com2014-04-25T22:37:55+00:00urn:sha1:daab651c5ca0d7198f6db2fa0abe2399fc08c69e
Also add some more debugging output to gc_dump_alloc_table().
Now that newly allocated heap is always zero'd, maybe we just make this
a policy for the uPy API to keep it simple (ie any new implementation of
memory allocation must zero all allocations). This follows the D
language philosophy.
Before this patch, a previously used memory block which had pointers in
it may still retain those pointers if the new user of that block does
not actually use the entire block. Eg, if I want 5 blocks worth of
heap, I actually get 8 (round up to nearest 4). Then I never use the
last 3, so they keep their old values, which may be pointers pointing to
the heap, hence preventing GC.
In rare (or maybe not that rare) cases, this leads to long, unintentional
"linked lists" within the GC'd heap, filling it up completely. It's
pretty rare, because you have to reuse exactly that memory which is part
of this "linked list", and reuse it in just the right way.
This should fix issue #522, and might have something to do with
issue #510.
py: Check explicitly for memory allocation failure in parser.2014-04-10T14:27:31+00:00Damien Georgedamien.p.george@gmail.com2014-04-10T14:27:31+00:00urn:sha1:58ba4c3b4c12e9bf6b8731fd26e0c9cac527122f
Previously, a failed malloc/realloc would throw an exception, which was
not caught. I think it's better to keep the parser free from NLR
(exception throwing), hence this patch.
py: Add emergency exception object for when heap allocation fails.2014-04-10T13:38:25+00:00Damien Georgedamien.p.george@gmail.com2014-04-10T13:38:25+00:00urn:sha1:f0954e3fac03c35a91e544c2ffddc12b82d7f8a0Improve GC finalisation code; add option to disable it.2014-04-05T19:35:48+00:00Damien Georgedamien.p.george@gmail.com2014-04-05T19:35:48+00:00urn:sha1:12bab72d93498958ddef26c1a2dd7c69a9f9cf8dMerge pull request #425 from iabdalkader/del2014-04-05T17:49:39+00:00Damien Georgedamien.p.george@gmail.com2014-04-05T17:49:39+00:00urn:sha1:8123a3339dc7381a079afa90649ce140075eb2e2
Implement delpy: Add m_malloc_fail function to handle memory allocation error.2014-04-04T10:52:59+00:00Damien Georgedamien.p.george@gmail.com2014-04-04T10:52:59+00:00urn:sha1:6902eeda259a5ed8fe3a5ce5cb19ba9207549d33
A malloc/realloc fail now throws MemoryError.
Implement del2014-04-03T21:55:12+00:00muxfreelancer.c@gmail.com2014-04-03T21:55:12+00:00urn:sha1:4f7e9f5c445b5c0b262d9dfb8fceda4830f4844bpy: Fix up so that it can compile without float.2014-04-02T16:06:05+00:00Damien Georgedamien.p.george@gmail.com2014-04-02T16:06:05+00:00urn:sha1:70f33cde48524f12f2110c7daa4a874a6828314a