Communicate JS memory pressure or GC to .NET WASM

[SerratedSharp]

Currently I am using Uno.Wasm.Bootstrap for supporting handles to JS objects from .NET using JSObjectHandle/IJSobject, which basically maintains an array of JS objects that each C# object indexes into. Once a C# object is garbage collected, then it removes the corresponding JS instance from the array making it in turn available for GC in javascript.

I would guess .NET's System.Runtime JSObject will behave similarly in terms of preventing the JS object from being GC'd as long as the .NET JSObject is alive, but I have not worked with it a great deal yet. I assume that is the reason it implements IDisposable.

Consider this scenario:

• I have a JSObject which is fairly tiny because it's minimal metadata.
• It references a very large JS object.
• I churn through a bunch of these, with them going out of scope and becoming available for GC.
• These are tiny, and .NET doesn't see sufficient memory pressure to perform a GC.
• Thus the .NET objects, while no longer referenced, live for a long time before being GC.
• Meanwhile, these large JS objects are filling up JS memory, but can't be collected because they are still referenced by the .NET objects, even though indirectly the .NET objects are no longer needed/nor referenced. You can get a JS out of memory without .NET ever trying to do a GC.

Obviously this falls under an "unmanaged resource" category and what really needs to happen is JSObject must be managed with using(){} blocks or similar approaches to achieve deterministic finalization. Often things that are IDisposable these days are instantiated through dependency injection, and in turn their lifetime is scoped to the request lifetime or are limited to a single instance across the application lifetime, making it something the dev almost can't screw up. That's not going to be appropriate for alot of use cases for JS object handles, since often you will be instantiating them based on logic, not as a dependency.

Managing IDisposable types imposes alot of restrictions on how code can be structured, impedes the general expressiveness of code, additional work, and it is always a potential pitfall. Because both systems conceptually have similar concepts of memory management, it seems like there's a real opportunity to free devs of these concerns and eliminate pitfalls by having the systems exchange information to facilitate coordinated GC.

If JS could signal to .NET (perhaps by exposing a GC event) that it has memory pressure and is about to do a JS GC, then .NET could first perform its own GC, which would ensure any unreferenced JSObject's are GC'd and allow the corresponding JS object to be freed in JS's subsequent GC. This would allow developers to be freed from managing deterministic finalization for these types.

I'm not sure if having JS GC "wait" for a .NET GC would be a concern though. Alternatively, exposing memory pressure metadata from JS to .NET might allow .NET to preemptively GC in anticipation of a JS GC without requiring the JS engine to hook up to .NET GC explicitly or wait for it. Another possibility is for JSObject to track metadata about the JS size of the JS object, and this could be used by .NET to aggregate estimates of JS memory usage for its JSObject's, and use that as a heuristic to influence when it needs to do a GC.

Some of these approaches I think could be implemented without explicit support of the WASM spec, but obviously some of them would require that. I admittedly can't really grok alot of what is in the spec to speak intelligently about it or make concrete suggestions. Hopefully you'll keep options to simplify memory management on your radar. Thank you.

[pavelsavara]

Yes, the JSObject and also JSException, C# delegate from Function, and Promise marshaled as Task hold handle to a javascript object. JSObject implements IDisposable, but it's voluntarily. If you don't dispose it yourself the managed GC would do it for you (at some point). The same is true for proxies in the other direction. There is also optional dispose() JS method on each proxy.

As you could guess having 2 GCs in the same process is quite challenging and that's reason why I think about those proxies as expensive resource.

• You should not create too many of them.
• You should do manual cleanup via dispose(), Dispose() especially if you know they hold large graph or large data.
• You could use weak references inside of your objects to hold such heavy dependencies, if that's easier than above.

Regarding memory pressure: We do register proxies on the JS side into FinalizationRegistry and therefore we know that some JS GC was triggered. But the WASM linear memory would not shrink anyway. The only possible outcome of that for JS would be that more C# proxies of JS objects are collected. Same idea about graphs/cycles of proxies could apply in the other direction too.

But I'm not sure that's reason enough to trigger (expensive) Mono GC for all users.
There is no (public) API to trigger browser JS GC.

By the spec, FinalizationRegistry could also do nothing or be very lazy about it. In practice, it is called but I don't have enough data to generalize, it could be very different based on the host device/OS running the browser and browser vendor. My conclusion is that you should not rely on it, if you have large resource to manage.

My 2c :)

@kg any thoughts ?

[kg]

Realistically speaking the solution to this is more robust cross-language GC integration. If you want to communicate memory pressure to .NET you need to know "how much" to communicate, and now you are reliant on .NET to not change its pressure thresholds/logic for GCs to happen when you want them. If they happen at the wrong times your app will feel unresponsive and freeze. For your scenario it may be most appropriate to just trigger a managed GC periodically on a timer to free unused resources.

In the long run we may be able to utilize WASM GC integration to hold onto JS objects directly somehow in a way that would alleviate this problem, but I'm not sure when/if that will happen due to the constraints of WASM and the status of the related specs.

[SerratedSharp]

I understand the caution, especially around generating unnecessaries GC's. Responding to a couple points from each of you.

I think about those proxies as expensive resource

Yes, taking that mindset addresses the current as-is implementation. REducing number of allocations, and fencing them with Dispose patterns avoids the problem since strictly they are unmanaged resources. Given current implementation this is what is appropriate.

I would like to encourage a more optimistic mindset, and not commit long term to the idea that it's a expensive in terms of a handle to a resource(obviously interop calls are another story), because that requires a high level of "carefulness" we must handle these with, elevated to the same level as say a connection or file handle where those patterns are a necessity.

Realistically speaking the solution to this is more robust cross-language GC integration. If you want to communicate memory pressure to .NET you need to know "how much" to communicate, and now you are reliant on .NET to not change its pressure thresholds/logic for GCs to happen when you want them.

Yep, if it's something that is kept on the horizon, because I really think there's probably an elegant solution somewhere that can be cautiously reserved to avoid excessive GC's.

If they happen at the wrong times your app will feel unresponsive and freeze.

I could imagine a mechanism that queues a deferred .NET GC from JS in cases where JS is approaching memory pressure, such that the GC request is only processed by .NET when there's an opportunity of little activity, to minimize visible impact. I think conceptually it's similar to GC Server Mode used to opportunistically garbage collect when it will have less visible impact.

At the other end of the spectrum, an immediate .NET GC would only be requested only under certain extreme circumstances. Maybe only if there's a JS GC which wasn't sufficient to bring it below its desired memory threshold, and only then trigger an immediate .NET GC. Or maybe even more restrictive is only in the worst case scenario where a JS GC was triggered by an attempted allocation, but the GC didn't free up enough for the allocation, so it then requests a .NET GC.

Consider if there was some such mechanism, and worst case scenario as a consuming dev you saw visible impact. Assuming the mechanism doesn't increase the number of GC's by an order of magnitude, then you probably already fall into a usage pattern approaching memory management problems.

I.e. in the absence of this mechanism, you're usage pattern is getting close to visible issues with current GC implementation, and probably should already be thinking about changing approaches to how you handle some of your more allocation "churny" bits of code.

I'm not sure when/if that will happen due to the constraints of WASM and the status of the related specs.

Certainly understood. I wanted to bring it up in case it had not been considered that there might be a happier solution somewhere over the horizon, rather than having to treat them as unmanaged resources eternally.

Thanks to both of you for taking the time to think about this. And thanks for your hard work on the interop implementations in .NET 7.

For your scenario it may be most appropriate to just trigger a managed GC periodically on a timer to free unused resources.

I don't want to focus too much on this, but anyone doing this would be rolling the dice on whether I get the right combination of allocations between the interval and crashing. You would say the same of this if someone had an unmanaged resource they weren't disposing of properly, and rather than find the root problem, they just added a timed GC.