Amusements and rantlings about the garbage collector

[massimosala]

I am using a esp8266 with the default GC config:
boot.py

import gc
gc.enable()
gc.threshold((gc.mem_free() + gc.mem_alloc()) // 4)

The program uses almost all the RAM. While it is running

• it calls gc.collect() and print these gc infos:
  mem_alloc = 33664
  mem_free = 4288
  threshold = 9488

• right after it calls a function and aborts

Traceback (most recent call last):
File "main.py", line 12, in
File "main2.py", line 514, in
File "main2.py", line 104, in config_search_last
MemoryError: memory allocation failed, allocating 512 bytes

I know that free memory is the sum of all free blocks, not the size of the largest free block.

Spelunking... I found this old discussion:
Memory allocation errors with plenty of space

@dhylands Dave I follow your suggestion: at the REPL, after the program aborts, I run

mbase = gc.mem_alloc()
a = bytearray(2000)
ma = gc.mem_alloc()

b = a[:]
mb = gc.mem_alloc()

c = memoryview(a)
mc = gc.mem_alloc()

print('allocating a took', ma - mbase, 'bytes')
print('allocating b took', mb - ma, 'bytes')
print('allocating c took', mc - mb, 'bytes')

Output:

> MicroPython v1.20.0 on 2023-04-26; ESP module with ESP8266
> Type "help()" for more information.
> >>> mbase = gc.mem_alloc()
> >>> a = bytearray(2000)
> >>> ma = gc.mem_alloc()
> >>>
> >>> b = a[:]
> >>> mb = gc.mem_alloc()
> >>>
> >>> c = memoryview(a)
> >>> mc = gc.mem_alloc()
> >>>
> >>> print('allocating a took', ma - mbase, 'bytes')
> allocating a took 2400 bytes
> >>> print('allocating b took', mb - ma, 'bytes')
> allocating b took 1584 bytes
> >>> print('allocating c took', mc - mb, 'bytes')
> allocating c took 576 bytes

Note: I don't call a gc.collect, I want to keep the current heap state.

At the REPL, the allocation of 2000 bytes succeeds.

Dave, you wrote on pyboard the memoryview takes 32 bytes.
Now on esp8266 the memoryview takes 576 byte ?!?!?!

---

@peterhinch Peter suggested to lower the GC threshold:
How to use the new GC threshold feature?

It seems to me that, to minimise fragmentation, once all modules have been imported and global buffers created user code should do something along these lines:

gc.collect()
gc.threshold(gc.mem_free() // 4 + gc.mem_alloc())

It doesn't help my program.

I fixed the program in two different ways, each of which, by itself, is sufficient:

• I rewrote the critical routine, replacing os.listdir with os.ilistdir ... too many files!
• In boot.py I set this GC threshold

gc.threshold(512)

QUESTIONS:

1. Why does the program stop complaining about 512 bytes ... and after at the REPL a request for 2000 bytes is successful?

2. Why is the GC threshold set so high in boot.py ?
   IMHO on micros with low RAM, it is beneficial to have a much smaller threshold.

3. Besides possible delays, are there any other side effects of using a threshold of 512 bytes?

I read the docs but don't really understand behaviour of the GC.
Specifically the rationale of the threshold set in boot.py towards the behavior of the GC at runtime.

[GitHubsSilverBullet]

The way you do your tests is highly misleading.
Try:

import gc

def test():
    mbase = gc.mem_alloc()
    a = bytearray(2000)
    ma = gc.mem_alloc()
    b = a[:]
    mb = gc.mem_alloc()
    c = memoryview(a)
    mc = gc.mem_alloc()
    print('allocating a took', ma - mbase, 'bytes')
    print('allocating b took', mb - ma, 'bytes')
    print('allocating c took', mc - mb, 'bytes')

test()

allocating a took 2016 bytes
allocating b took 2032 bytes
allocating c took 16 bytes

[rkompass]

I have to do a gc.collect() at the start of test() to get reasonable numbers. With that similar to your results @GitHubsSilverBullet on my esp8266.

[jimmo]

To elaborate on what @GitHubsSilverBullet is saying -- when you are testing this at the REPL, you are also including all of the allocations done by the compiler to evaluate what you typed in.

So the 2400 bytes of allocating a took 2400 bytes includes ~400 bytes of allocations done by the compiler and the emitter for the bytecode that is going to execute.

The version that @GitHubsSilverBullet shows is far more accurate because you're decoupling the compiler/emitter from the actual test you're doing.

2016 bytes for a is correct because it's 2000 bytes of buffer, plus 16 bytes for the bytearray object. 2032 for b for the same reason, plus 16 bytes for the slice object that was created in a[:].

c is 16 bytes because a memorview is 16 bytes.

Allocations can't be smaller that 16 bytes (that's one gc block).

To answer your questions -- increasing decreasing the threshold just means that the device will always be working as hard as possible to free, but also has the secondary effect of resetting the "next allocation" pointer back to the earliest free location in the heap, which further has the effect of reducing fragmentation.

In other words -- gc.threshold allows you to trade performance/latency for GC fragmentation.

[massimosala]

Hi @jimmo

I know about the trade-off.

I am puzzled between the docs and your comment.

From
gc.threshold([amount])¶

If this function is called, in addition to OOM, a collection will be triggered each time after amount bytes have been allocated

Reading after amount bytes I understand that to have a more aggressive GC (slower is fine, my first concern is to compact the heap) I have to set a lower threshold.

As I wrote, I am about to exhausting the free memory, gc.mem_free() report about 1500 bytes.

With the default policy
gc.threshold((gc.mem_free() + gc.mem_alloc()) // 4)
my program crashes just importing modules or running the first instructions.

Updating boot.py with a very small threshold, like
gc.threshold(256)
my program runs (web server, ntp client, handling IO pins, ...) or, at least, crashes after many operations (I still have some stray allocations, like array slicing where a memory view is not usable).

Forgive me, I cannot match your explanation with the official doc.
Are you sure that a higher threshold causes more aggressive GC ?

[jimmo]

Yes sorry that was a typo. I meant "decreasing the threshold" (i.e. increasing the rate at which the collector runs).

[massimosala]

Thanks to all for your feedback.

[massimosala]

A follow-up about modules.
Following your suggestions, working only with the REPL.

My program is composed of about a dozen modules.
Some modules contain basic functions, called by the other modules.
The usual

module2.py
from utils import a, b, c

module3.py
from utils import b, f

and so on...

Working at the REPL, after a soft reset, only boot.py executed.

>>> import gc
>>> gc.collect()
>>> gc.mem_free()
36160
>>> from ntptime2 import *
>>> gc.collect()
>>> gc.mem_free()
29216


>>> import gc
>>> gc.collect()
>>> gc.mem_free()
36176
>>> from ntptime2 import LOCALTIME_BASE_YEAR
>>> gc.collect()
>>> gc.mem_free()
29504

I thought it would be better not to import * but here importing one object consumes the same memory ?!

I ask for your feedback.

[massimosala]

@GitHubsSilverBullet Hi! Can you please help me about this last question?

[scruss]

I thought it would be better not to import * but here importing one object consumes the same memory ?!

MicroPython has to import the whole module even if you're only using one part of it. That's why you're seeing the same memory usage from from lib import * as from lib import item.

[massimosala]

Hi Stewart. Thanks for replying to my SOS.

So partial imports are useless?

I have one main and a dozen modules.
Thinking to save memory (there is about 2Kb of free heap with the program running on esp8266), in the various modules I took care of the imports. Like:

moduleA
      from basic import func1

moduleB
      from basic import func1, func3

moduleC
     from basic import func2


Did I do this for nothing?
Maybe calling the same module, might as well (or maybe it's even better) to call it in the other modules with a
`from basic import *
`
?

[scruss]

So partial imports are useless?

Yes. Your board might even be importing some modules in its hidden _boot.py script that you don't need to import again. You're not going to waste memory by importing multiple times, but you're not going to save anything either.

[jimmo]

So partial imports are useless?

Yes. There's no other way this could work because Python has to execute the entire module to figure out what's available.

Consider mod.py:

if ...something...:
   def a():
      pass
else:
   def a():
      pass

Then code that uses it

from mod import a

[massimosala]

Hi Dave @dhylands

Could you please take a look at my last comments?

A long time ago, in a galaxy far away... https://github.com/orgs/micropython/discussions/11804
you wrote:
If you import Module A, do a collect, import Module B and do a collect, then you'll still have 2K allocated, but it will now be in the bottom 3K of the heap instead of the bottom 6K of the heap (i.e. less fragmented).

Are you suggesting it is a good practice to call a gc.collect() after every import ?

If yes, should micropython do it by itself when importing modules?

[jimmo]

@massimosala Yes this has been discussed in many places, and as always there are tradeoffs. Doing this by default would have a non-trivial performance impact for example.

My understanding is that CircuitPython does implement this though.