hermes: Garbage Collector not picking up high memory pressure when memory is allocated in native HostObjects

Bug Description

Background

There are multiple reports about memory issues in Hermes that seems to be caused by or be related to the garbage collector in Hermes not picking up native allocations done in C++ based HostObjects.

A host object can allocate memory using malloc or other mechanisms, and the Garbage won’t see this memory. This again causes the host object to be considered too small to be garbage collected and for performance reasons will be kept alive.

We’re seeing this extensively in our React Native library @shopify/react-native-skia where the Skia API is implemented in C++ as Host Objects using JSI.

Example

An example is our image component where we allocate and load images that can be of any size. The Hermes Garbage Collector will only see our image component (which is only pointed to by the Javascript engine, we don’t keep any internal registries of objects - they’re always returned and kept alive by JS) as a super small JS object and never deallocate this.

We’ve used some tricks like providing hooks that cleans up the allocated memory to make this work, but some of our objects are not exposed through hooks and will therefore not be cleaned up by GC.

Testing

We’ve tested these things switching back and forth between JSC and Hermes which verifies that this is an issue.

References

Here are some references to other issues in the Hermes repo that might be related:

• [Hermes] : leak in hermes when using rxjs
• fetch() BlobModule.java memory leak still exists on hermes-engine 0.9.0
• Memory consumption on iOS
• Out of Memory Issue

We’ve also seen some references in other repositories like this one from @Kudo in react-native-v8:

• fetch() BlobModule.java memory leak fix not working if enable v8 js engine

In @shopify/react-native-skia we have multiple issues regarding this and are constantly fixing new ones (and trying to change anti-patterns that allocate too many times like in animations):

• Memory Leak when Navigating on iOS
• Mount/unmount of a Canvas element causes a memory leak

Alternative Solutions

There are several ways to move forward to solve this issue, the first one being us library developers being better at not using anti-patterns where we’re not cleaning up after us. This is however not always easy, and a lot of the native code implementing HostObjects are doing so with the assumption that if you let Javascript / Hermes manage an object’s lifespan everything should be good.

We can also look into expanding the jsi::HostObject interface to expose information about how much memory an object has allocated which can then be picked up by the garbage collector and used when calculating which objects we should free.

The garbage collector might need to look into not only its own allocated memory, but also the total memory used by the current process.