CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.1.x 2020-11-28T16:50:23+00:00 2020-11-28T16:50:23+00:00 Christian Walther cwalther@gmx.ch 2020-10-11T12:59:33+00:00 urn:sha1:c7404a3ff89c738c002ec63448a58d56330dfcc3 This allows calls to `allocate_memory()` while the VM is running, it will then allocate from the GC heap (unless there is a suitable hole among the supervisor allocations), and when the VM exits and the GC heap is freed, the allocation will be moved to the bottom of the former GC heap and transformed into a proper supervisor allocation. Existing movable allocations will also be moved to defragment the supervisor heap and ensure that the next VM run gets as much memory as possible for the GC heap. By itself this breaks terminalio because it violates the assumption that supervisor_display_move_memory() still has access to an undisturbed heap to copy the tilegrid from. It will work in many cases, but if you're unlucky you will get garbled terminal contents after exiting from the vm run that created the display. This will be fixed in the following commit, which is separate to simplify review. 2020-05-09T19:16:04+00:00 Max Holliday maholli@stanford.edu 2020-05-09T19:16:04+00:00 urn:sha1:964040b7702a66f44aa8e9f4af6cf74712ed44ed 2020-05-09T19:09:01+00:00 Max Holliday maholli@stanford.edu 2020-05-09T19:09:01+00:00 urn:sha1:8b6587a0c646089608b0c8bbace97a73462cf88f 2020-05-09T19:03:26+00:00 Max Holliday maholli@stanford.edu 2020-05-09T19:03:26+00:00 urn:sha1:9e01bb213617fd46723f3dbb869ba51c1985ac21 2020-05-04T20:08:45+00:00 Dan Halbert halbert@adafruit.com 2020-05-04T20:08:45+00:00 urn:sha1:c377d4bea79710bdf3880dfdbd2970f1ee7fc373 2020-04-29T01:15:38+00:00 Max Holliday maholli@stanford.edu 2020-04-29T01:15:38+00:00 urn:sha1:cc290c50c677e16ccdddae74ab0861c9101727fc 2020-04-28T18:51:07+00:00 Max Holliday maholli@stanford.edu 2020-04-28T18:51:07+00:00 urn:sha1:6c4decd4e280d30c6b45ed74ac3e0c9b12194cd9 2020-04-08T01:17:25+00:00 Max Holliday maholli@stanford.edu 2020-04-08T01:17:25+00:00 urn:sha1:826837186c9668805b58edb4e57b68363aba0149 2020-03-13T18:12:31+00:00 Scott Shawcroft scott@tannewt.org 2020-03-10T22:05:42+00:00 urn:sha1:ed5cdd7e0970b904ed001deabe051c48ac32b1d3 2019-12-10T23:07:20+00:00 Jeff Epler jepler@gmail.com 2019-12-10T23:05:37+00:00 urn:sha1:f4a5c17b5e79cf9bd02be248620d445065891a25 It's extremely dubious that we have these handles that we think are to GC'd memory at a time when the gc pool may not be initialized. Hopefully, they WERE valid GC memory and are undisturbed by the teardown of the interpreter that can lead to this state. In this case, don't try to m_free them, the memory will become free when the GC heap is reinitialized. Closes: #2338 (together with previous commit)