Code size report:

Reference:  tools/mpy_ld.py: Allow overriding the internal MPY file name. [b49f098]
Comparison: rp2: Enable no-scan GC. [merge of 1fb9532]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:  +108 +0.012% RPI_PICO_W[incl +4(bss)]
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.51%. Comparing base (b49f098) to head (1fb9532).

@@           Coverage Diff           @@
##           master   #19367   +/-   ##
=======================================
  Coverage   98.51%   98.51%           
=======================================
  Files         176      176           
  Lines       22904    22905    +1     
=======================================
+ Hits        22563    22564    +1     
  Misses        341      341           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

This incredibly unhelpful graph illustrates that there's a very real, if vanishingly small cost to adding this change, affecting routing garbage collection in smaller memory environments.

It's only paid if the feature is turned on however, and the relative benefit for even modest buffers (96k is absolutely peanuts on 8MB PSRAM, but this was tested on an RP2040 to show the worst case tradeoff) far, far outweighs any cost.

And here's the same test on a Pico LiPo 2 with 8MB PSRAM enabled:

What each test measures

• frame_manual - Per-frame time (us) of a render loop that allocates a 1 KB bytearray + a small list each frame and calls gc.collect() EVERY frame (predictable pacing). p50=median frame, p99/max=worst-case stalls.
• frame_ondemand - Same render loop with no manual/threshold control - GC only fires when the heap fills (cheap average, large spikes).
• frame_threshold - Same render loop, but using gc.threshold() auto-collection instead of collecting manually.
• churn_per_alloc_ns - Per-allocation time (ns) churning 50000 transient 4-element lists - allocation throughput including amortised GC.
• collect_empty_us - gc.collect() pause (us) on a near-empty heap - the fixed overhead of a collection.
• collect_3000_lists_us - gc.collect() pause (us) with 3000 live small lists (real pointers) - these must be scanned, so no-scan cannot help.
• free_start - Free heap (bytes) after a full collect at start. Higher is better; the no-scan table costs ~1 bit/block of heap.
• collect_96k_bytearray_us - gc.collect() pause (us) with one live 96 KB bytearray. The headline case: a large pure-data buffer the mark phase would otherwise scan word-by-word for pointers.

Note that the 96k bytearray is only allocated in that specific test, since it would massively skew the other tests in favour of this feature being turned on.

And since those were so bad, here's a graph which cuts right to the gist of the change:

Again I'm shooting low here, this is just the difference in collect times in SRAM, which probably makes it a reasonable sell even for a stock Pico 2 / Pico 2 W. PSRAM's speed (or lack thereof) compounds this effect.

Since this ties in strongly with the optimised tail scan (#19363) here's a graph of them working together, again just SRAM:

Very persuasive graphs!

Of note, @tannewt implemented a very similar idea in CircuitPython last year, see adafruit#10264. CircuitPython went even further and updated most of the places they call m_malloc(). Not saying we have to follow their example instead, but it's useful to consider as an alternative base (and their implementation has been quite heavily tested at this point, I assume).

The main potential for problems I can see comes from code which might play fast and loose with what they keep in the bytearray. For example, use of uctypes.addressof(buf) and then the caller assumes they can store pointers to other data in that uctypes structure and have the other data stay alive. This pattern is rare enough that perhaps we could add a gc_mark_for_scan(ptr) C API that re-tags that buffer, and call it from the the implementation of functions like uctypes.addressof().

Of note, @tannewt implemented a very similar idea in CircuitPython last year

I've heard plenty of rumblings of long-lived data and seen some of @tannewt's videos diving deep into GC. They have such a closely aligned set of problems to what we (Pimoroni) deal with (big silly fun hardware projects) so it figures! I'll have a glance over and see how it compares. (I think it's obvious, but I kinda got carried away with this stuff, since we really wanted the extra perf downstream and were happy to own scary changes)

perhaps we could add a gc_mark_for_scan(ptr) C API that re-tags that buffer, and call it from the the implementation of functions like uctypes.addressof().

I did wonder about having an explicit opt-in to make a memory region no-scan, but it feels like no-scan is the typically happy path (short of C bindings which allocate structs or objects that contain pointers... something I was repeatedly bitten by in the early days of my Pico exploits) so opting in to scan makes a lot of sense (as long as you, uh, don't forget).

I'm currently deep into benchmarking, verifying and testing a complete rewrite to GC to peer into the hypothetical future of what we could possibly gain. For large RAM allocations this skip change still absolutely demolishes any other optimisation we could make directly to GC, and I'm poised to ship this in our Badgeware builds for road testing.