How to free memory manually

[Wenjie Wu]

I noticed that in a websocket application, when the free memory gets low , the microblocks websocket service stops serving (client blocked) until the value shown in the free memory automatically gets larger and the service becomes normal again

[Wenjie Wu]

I had a similar problem with the Microblocks http server before, where after multiple requests-responses, there would be a client request that could not be responded to, but then next request would resume, seemingly due to the automatic garbage collection.

In these cases, it seems that if I can manually free the memory, I can avoid the problem.

[John Maloney]

It should not be necessary to force a garbage collection (GC) since the system will do it automatically when needed.

However, if you want to experiment, you can try to allocate a huge object, such as a million element list:

That will give an error but will force a GC.

You can also click the stop button to clear all variables and free all objects. If you click the "free memory" right after that -- before running any scripts -- you'll see how much dynamic memory (in bytes) is available in MicroBlocks on your board.

It is possible that the problems you are seeing are because MicroBlocks is running out of memory so it cannot allocate memory for new objects, even after a GC. That could happen if, for example, you were collecting incoming data in a list. In that case, you'd need to remove unused items from the list to allow the memory to be recycled.

Another possibility is that requests are arriving faster than they can be handled, thus creating a temporary memory shortage. A garbage collection operation takes a few milliseconds, which might cause a backup. Writing data to the Flash file system can be very slow. A possible fix for such timing issues is to slow down the sending program.

Note that the ESP32 has much more RAM available for MicroBlocks than the ESP8266. If you are experienced problems on an ESP8266 you might try running the same program on an ESP32.

[Wenjie Wu]

It is possible that the problems you are seeing are because MicroBlocks is running out of memory so it cannot allocate memory for new objects, even after a GC. That could happen if, for example, you were collecting incoming data in a list. In that case, you'd need to remove unused items from the list to allow the memory to be recycled.

Yes! It was exactly what I was having trouble with, and with your tips, it's working perfectly now!

Thanks John！

‌

Another possibility is that requests are arriving faster than they can be handled, thus creating a temporary memory shortage. A garbage collection operation takes a few milliseconds, which might cause a backup. Writing data to the Flash file system can be very slow. A possible fix for such timing issues is to slow down the sending program.

This tip is also very important！

‌

[John Maloney]

Glad you got it working!

What board were you using? You're more likely to hit memory issues on an ESP8266 than an ESP32. All microcontrollers have tiny amounts of RAM compared to the multiple gigabytes we have modern desktops, laptops, and mobile devices. Even a $5 Raspberry Pi Zero has 512 megabytes of RAM, thousands of times more than most microcontrollers. When you're used to have so much memory, it's hard to remember that RAM is a scarce resource on microcontrollers.

[Wenjie Wu]

What board were you using?

I am currently using ESP32, this problem is solved by reseting the list variable in time.

When you're used to have so much memory, it's hard to remember that RAM is a scarce resource on microcontrollers.

Yes, it is : ) It has another kind of fun.

‌

[John Maloney]

It has another kind of fun.

Yes, I also find it fun work in the constrained world of microcontrollers. :-)

[Wenjie Wu]

Art is dancing with shackles . Programming, sometimes, is an art disguised as a science : -)

[Wenjie Wu]

I think Microblocks is an elegant art :-)

‌