Possible issue with `Module.removeAllCached()`

Hello folks!

We may have a memory leak with Module.removeAllCached(), which is pretty ironic since I hoped to use it and free some memory ;P

A bit of context. I'm trying various means to overtake the deadly 10000 character limit.
From the last month experiments, this is roughly the maximum number of symbols your application could have to fit in the Bangle's RAM.

I found a nice way to split my code into several chunks, each being a file.
My ES6 source code is leveraging dynamic imports, which instructs Rollup to produce several chunks.
A small Rollup plugin of mine turns the chunk into Bangle's files.
The app is written so screens are stored as files. Displaying a screen is simply requiring the relevant file, and calling the build() function it exposes.

Here is the code,
and here is the minified, split output that you can run on your watch.

Now if you launch the app, and cycle through the various screens with middle button, at some point you should have a LOW_MEMORY error.

Since object returned by require() are cached, I've tried to call Module.removeAllCached() after a screen was required, so it could claim the space from the previous screen.

Here is the minified code, same as previously but with the call.

You'll be surprised to get the LOW_MEMORY error the very first time you load next screen.
Few more experiments makes me believe that Module.getCached() also have similar side effect.

Could it be that listing cached modules (which removeAllCached() starts with) is eating more RAM that it should?

Hi,

I'd be reasonably sure that there isn't a memory leak, as removeAllCached has been around for 5+ years and I'd have thought this would come up already if there was a problem.

I imagine most likely you still have a reference to some part of the module that you loaded kicking around? Potentially typing dump() in the LHS might give you some clues. If there is a reference, even though the modules list is empty you'd still have the data kicking around.