How to use gc to manage resources

[oovm]

I have a handle to a huge tensor (GTensor) on the gpu, the size is u64(ptr) + u64(len).

I hope that all other operations will use its reference (GView), and if there is no reference, the resource will be recycled by js side gc.

Should I define GTensor as resource and GView as record?

I'm not sure about the implementation of wasm-gc, and how to reclaim this resource at runtime.

Is there a best practice for gc resources?

Or the gc proposal has not been implemented, and I should wrap it internally as Rc<RecCell<GTensor>>?

[alexcrichton]

I'd recommend using a resource to represent GTensor, and then GView would be a borrow<_> of that same resource. Resources have ownership and destructors, meaning that you'll be able to run code when wasm drops it.

Does that work for your use case?

[oovm]

Do I need to manually call nn:buffer/g-tensor#[dtor]g-tensor on the js side to ensure the release?

If it has been released by gc, what will happen if I call it again.

---

Or js should only operate the view version.

When all views and related closures are inaccessible, then the js engine will do the rest for me.

[alexcrichton]

It sort of depends on what you mean, but the answer is in general "no" I think. If you're running JS in the guest, e.g. using componentize-js, then that should already have the hooks to run the destructor when the JS object falls out of scope. It may also be the case that there's an explicit finalizer you can call, but that should be just an optional performance improvement.

If you're running JS on the host and handing resources to a component then you should have a finalizer callback to fill in. That will get invoked by the component runtime when the component drops a resource. Until that's called the component is still using the resource.

I'll also clarify that what I'm saying here is conjecture as I'm not intimately familiar with the JS support for resources. This is what it was planned to look like, and I have no reason to think that there's any deviation, but I'm not running code in front of me to confirm all this.

[oovm]

Ok I need some time to confirm the actual behavior.

This thing is difficult to debug because the debugger also holds a reference to it, which prevents recycling.

I can only observe if there is a decrease in memory usage, but it is not obvious.

[oovm]

Does wit-component have a concept similar to weak reference, so that it can hold its reference but not affect its life cycle?

[alexcrichton]

Sorry I think I'm going to need to you to be a bit more specific. What debugger are you using? What host are you using, and what guest are yo uusing?

Currently wit-component works with the component model which has no GC types and additionally has no weak references as a result.