Do you have any actual problems that would be solved by this, or evidence that jank is actually caused by GC? I've never been a huge fan of garbage collectors but browser's modern GCs are pretty good and do generally slice work in to small (non-janking) updates and concurrent collection. I haven't seen GC obviously causing jank for some time now. Most jank issues seem to come down to some kind of system v-sync timing issue, and the last other cause I saw in the forum, was forcing synchronous texture loading during gameplay.
That's indeed the case for the most jank reported on the forum, Vsynctester in my opinion the best proof for v-sync timing issues and jank but that's another topic for another day and I'm aware of synchronous texture loading during gameplay jank, that's why I proposed a new memory management system on the C3 ideas website.
I've slightly modified an example that demonstrates force unloading. Please note that this is incredibly difficult to reproduce on systems with 8gb+ memory, however not impossible since I managed to reproduce it a couple of times myself.
Download example & Steps to reproduce:
- Launch example in NW.js (tested in v0.28.0)
- Load stuff into memory by clicking "load all audio files into memory" button (about 1gb total)
- Tell GC to unload stuff by clicking the button
- Switch to the "game" layout by clicking the button on the top-right corner
- Observe GC unloading memory "mid-game" causing major jank (this process happens at random, sometimes immediately, sometimes delayed)
Repeating myself here but despite GC being considerably great for the most part, the main issue persists: control.
I'm sure you know this already since you've worked on native software yourself but an important thing to software and game Dev's alike is to have control over memory usage. While having an unpredictable automated GC system like this in place can be an amazing thing, it doesn't always work out with every project and having an optional method to manually manage memory would be tremendously useful for those projects, regardless of them being a small minority in comparison to others that don't need it.
The GC is designed to as far as possible only use the lower levels of GC and avoid expensive full heap collections, and even then if it has to, it tries to do it concurrently...
My example proves this to be wrong. If executed correctly, you will be able to see that GC pretty much unloads everything at once, same as when it's being forced.
Also I'm not sure but it might even force it to be synchronous (no time slicing/concurrent work). Browser GCs are also generally pretty good at scheduling these only when it's needed, so if you force one ahead of time, chances are it's not needed and there's not much point doing the work. So, in fact, adding this could make jank problems worse, not better.
I've been told that this feature is exactly like pressing the "bin" icon in Dev-tools. Would you mind providing some sort of proof that it's indeed causing those problems? I'm using it in my project for a while now and I've never experienced any issues with jank getting worse or GC not working correctly after manually forcing it, even if it would cause GC to stop doing things automatically, I would consider that be a good thing and not necessarily a bad thing.