search

Moddable-OpenSource / moddable

Tools for developers to create truly open IoT products using standard JavaScript on low cost microcontrollers.
http://www.moddable.com
1.32k stars 236 forks source link

Compartment.evaluate chunk/slot leak #1400

Closed cmidgley closed 4 weeks ago

cmidgley commented 4 weeks ago

Build environment: Windows Moddable SDK version: 4.9.0-14-g2d3b810d6 Target device: Win (sim) and ESP32

Description Compartment.evaluate appears to have a memory leak of 16 bytes on the chunk heap and 12 bytes on the slot heap on each call.

Steps to Reproduce

  1. Clone this repo
  2. Run (win and esp32 tested) to see a loss of 1600 bytes of chunk heap and 1200 bytes of slot heap, across 100 usages of evaluate

In the example repo, I use Debug.gc() before each Instrumentation collection, which I believe should report fairly accurate numbers. I have found this leak scales linearly with usage, and does not appear to depend on what is executed (empty script and complex scripts both have the same resulting heap usage).

phoddie commented 4 weeks ago

Would you believe that this is debugging feature?

The leak does not occur in instrumented or release builds. Here's the output from an instrumented build:

Leak test at 2024-09-01T23:08:31.514Z for 100 iterations
Chunk heap usage: 0
Slot heap usage: 0

What's happening is that XS is making the source text of the evaluate (or globalThis.eval) available for debugging. To do that, a dynamic identifier (path name) is created and the source text is transmitted to xsbug which caches it on your computer. XS uses a symbol to hold the path to the source text. The memory use you are seeing is that symbol.

You can disable the transmission of source text on ESP32 by removing these lines. If it would help, we could add a flag to disable that at compile time.

FWIW – in theory that symbol can be garbage collected when the byte code is no longer referenced. XS doesn't do this because it would make garbage collection much slower as it would require scanning byte code to determine symbols in-use.

cmidgley commented 4 weeks ago

Thanks for explaining what's going on. It makes sense and no need to add any flag. I'll try release mode when investigating similar issues in the future.