Garbage collection of HostObjects

[alielmorsy]

Hi,
I’m exploring the world of Hermes with JSI, and I came across something a bit strange. I’m not sure if I did something wrong, but I’ve been debugging for hours and haven’t found anything.

The issue is that the host object may persist for the entire session until the runtime is destroyed. I tried tweaking the runtime GC configuration, but nothing worked.
Is there a way to avoid this issue (besides manually calling gc, of course)?

I discovered this because the host object holds a shared pointer to one of my internal structures, which I need to be destructed periodically to free up memory.

[neildhar]

Hi @alielmorsy, we've addressed similar issues in the past (e.g. #982), but we'd need a lot more information to have a sense of what might be happening.

1. What version of Hermes are you using?
2. Can you share a minimal repro that exhibits this problem?
3. Does manually calling gc() collect the HostObject as expected?
4. Have you tried using setExternalMemoryPressure to inform the GC of additional retained memory outside the JS heap?

[tmikov]

@alielmorsy to be absolutely clear: the two issues you linked do not describe an actual problem and thus need no solution. To the best of our knowledge everything is functioning correctly and as intended.

There is a very common misunderstanding of how garbage collection works and what guarantees it can provide. Garbage collection does not guarantee when an object will be freed or even that it will be freed at all. GC uses heuristics to maintain a certain ratio between the size of the free and used memory. It only runs when it deems necessary - say, when memory pressure builds up - so if an application has plenty of memory and no need to reclaim space, unreachable objects might linger indefinitely. This means cleanup tasks tied to garbage collection, like freeing native resources, cannot be relied upon to happen predictably or ever.

This is true across all garbage-collected languages. In Java, for example, the guidance is to always explicitly close resources like files and never rely on finalization, a lesson that holds for any language with GC. That is why Java introduced try-with-resources.

The correct design for owning a native resource in a GC language is to separate the lifetime of the object (the HostObject in your case) from the lifetime of the resource. That means that you must provide a close() method or similar, which should be explicitly called by the user code when it is finished with the object, even though the object is still reachable. If the user forgets to call .close(), the GC will either eventually free the HostObject, which will also free the resource, or the process will eventually terminate.

Here is relevant explanation from C# as an example:
https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals#unmanaged-resources

Finally, this is a proposal that addresses this in JS: https://github.com/tc39/proposal-explicit-resource-management

Sounds like you are already reaching similar conclusions for your design, though I don't see why you wouldn't be able to use shared pointers.

[alielmorsy]

@tmikov Well, thanks for your explanation.
The reason for avoiding shared pointers inside the Host object is that there is a pool for the native pointers. We don't create as many objects as mentioned in the other discussion, but we do create and free a lot of them. To optimize this, I decided to use a pool to avoid frequent freeing and reallocating by reusing the same pointer. To make the pool easier to implement, I used a custom deleter for the shared pointer, which eventually returns the pointer to the pool. This allows me to keep the existing code intact while adding pool support.

However, this resulted in half of the objects always being referenced somewhere else, specifically by the Host object. At first, this was manageable, and I could work with it. The real issue arose when I discovered that these objects were holding references to some Hermes Value objects, leading to a dangling pointer assertion.

I'm still thinking of a solution, though.

[alielmorsy]

I went for weak pointer temporary inside the host object. Anyway my backend will be aware when the host object is not used anymore (In most cases). I will go around with this solution for now but I guess I will come back again to this implementation later when I have time.

[tmikov]

@alielmorsy FWIW, we recommend against using HostObject. NativeState is the recommended approach for attaching native data to a JS object.

[alielmorsy]

Wow! Didn't see NativeState anywhere before. I will check the code to understand more how it works. Thanks for the help @tmikov really appreciate it