Expose a small portion of Mono's VM API to C#

[ghost]

Describe the project you are working on: I am working on a huge modding framework that uses a custom pool manager to manage a pool for every custom type in order to provide the best from both worlds: cache/allocator friendly memory management from DOP, but also a direct OOP handle to the underlying object(s) in pool. Describe the problem or limitation you are having in your project: Most of the stuff that implements IPoolable interface and that gets passed to my custom pool manager is fine, but what bothers me is that most of the Godot's C#-reflected classes do not provide a way of cleaning themselves up. I am not talking about resources that are managed by native handles inside of those objects, but about objects themselves. Describe the feature / enhancement and how it helps to overcome the problem or limitation: It would greatly benefit to expose Mono's VM API to manually delete objects without waiting for GC to do its job when it will feel like doing so. Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: Something like Godot.Mono.Delete(object Target); that will simply be a reflection of Mono's inner method to delete MonoObject. Or maybe even provide a way to toggle GC altogether, and then allow people to fully rely on manual deallocation. If this enhancement will not be used often, can it be worked around with a few lines of script?: There are languages like Beef that are existing to solve this issue, by taking C# syntax and stripping down things like memory virtualization, but most importantly - GC. If this feature is going to be implemented in the additional namespace, then it will not provide any overhead to C# developers that prefer to write code while relying on GC and would also provide an option to a lot of experienced developers to manage their objects in C++ manner. Is there a reason why this should be core and not an add-on in the asset library?: My reasoning is above, and I also wrote a comment down below explaining why would a lot of people will find this beneficial to have access to.

[Calinou]

cc @neikeq

[ghost]

I would like to expand on my issue and explain my concern as to why I brought this issue up. ALL of my types' allocations are handled through pool factory, but most of the external classes that are provided from third-party libraries (including Godot's C# classes) do not provide any reasonable way of reusing them as any other poolable entry, and due to that uncertainty I would still love to have an ability to deallocate those objects on my own.

I am aware that C++/C# binding of Mono methods is not going to be on par with native GC cleanup processes, but having control over the lifetime of those objects would still be beneficial. Even in the provided example down below this solution will help us to deduce potential time spent on GC:

Let's say that we have 10 big objects that we can deallocate during the runtime at any moment with Godot.Mono.Delete in 7-8ms, and we would have a total of 70-80ms of combined time for deallocation due to overhead. And let's say we are going to dereference those same objects instead of deleting them, then we will wait for GC, and we would get 2-3ms delay for each, and 20-30ms of combined time, but instead of barely noticeable 7-8ms delays every time when we would need to deallocate those objects, we would get a combined ~20-30ms lag spike.

What I am trying to say is that no matter what performance overhead this solution will provide, it would still be beneficial to prematurely delete objects that we actually no longer need, then to wait for them all to be collected at once with GC, which would potentially introduce lag spikes during the gameplay.

[neikeq]

What Mono API allows to delete a managed object? AFAIK this is not possible at all and the GC takes care of everything. If it's about releasing the native handles associated with a Godot C# class, then there is Dispose. But it doesn't look like that's what you meant.

[ghost]

After researching multiple opensource .NET runtime implementations, I decided to drop C# completely.