What is the problem this feature will solve?

Context:

In the Rolldown project, we need to attach a large of data to a js object. Only when properties of that object get accessed, which are getters, the data will be pulled back to js. So a classic lazy data pattern.

The problem we think/suspect is that the object is too small to be captured by the GC, which causes a large of external memory hang there.

What is the feature you are proposing to solve the problem?

Similar to napi_adjust_external_memory, it would helpful to have a napi_adjust_external_memory_of_ref/object to specify how how much external memory that an object might holds, so the object gets a high priority for the GC.

What alternatives have you considered?

Currently, to solve the problem:

• We use WeakRef<T>[] to collect all objects that hold external memory
• We provide .close as an explicit way to allow user free resources manually
• When .close getting called, we go through the WeakRef<T>[] and calling userland method to free external memory and pull the data back to js to make sure these js objects are still alive after cleaning up.
• If .close doesn't get called, we'll still encountering the issue.