Is there a GOMEMLIMIT analog in TinyGo?

[vlkv]

Hi!

In my case I have an app which produces a lot of garbage and it crashes with OOM because of that (not a memleak). TinyGo's GC could be more aggressive at times when occupied space is close to some soft limit, set by GOMEMLIMIT (This env is from the Google's Go https://pkg.go.dev/runtime#hdr-Environment_Variables).

[dgryski]

The TInyGo garbage collector first searches for enough space to satisfy the allocation; if that fails, then it runs a garbage collection and tries again; if that fails to find enough space, then the heap size is increased until the allocation can be satisfies or the underlying system runs out of memory. If you're encoutering OOMs then my guess is you're experiencing memory fragmentation which is impeding the garbage collector. There is enough space free, just not in a contiguous block.

[vlkv]

@dgryski Thank you for your comment. I am experiencing that after refactoring, my app gets OOMs in some test cases. I have studied the code before and after and cannot find a cause (the code before the refactoring creates a lot of small objects too, so if it is a memory fragmentation, then why the things got worse, I cannot explain)... I am using the -gc=precise and target is wasi BTW.

Are there some debugging tools available for TinyGo that could help to diagnose the roots of the OOMs? For example:

• pprof for TinyGo?
• some debugging log from GC?
• anything else?

[ralfuslongus]

@dgryski: Have you found any answers regarding debugging tools yet? I am on the search for tools or general procedures to find the reason for OOMs in tinygo too