When am I expected to call V8Entity_Release and V8Entity_DestroyHandle?

[AnsisMalins]

Can I get some hints re: when am I expected to clean things up when talking to the C++ side of ClearScript directly? Do I need to clean up any of the values that I receive from the callbacks in V8SplitProxyManaged (for example, GetHostObjectNamedProperty)? When I receive e.g. a Uint8Array (as a V8Value that I then decode to a pointer to the array) as an argument in a function call, do I need to release it when I'm done?

What of this example? What, if anything, is it leaking?

// There are ScriptInvoke and InvokeNoThrow higher up the call stack already, so no need to do them again?

var scriptItem = (V8ScriptItem)ScriptEngine.Current.Script;
var script = (V8ObjectImpl)scriptItem.Unwrap();
using var value = V8Value.New(); // V8Value is a readonly ref struct that wraps a V8Value.Ptr

// I've added versions of the native interface methods that take a V8Value.Ptr instead of returning an object.
V8SplitProxyNative.Instance.V8Object_GetNamedProperty(script.Handle, "EngineInternal", value.ptr);

var engineInternal = (V8Object.Handle)value.Decode().PtrOrHandle;

// Does overwriting the V8Value release the refcount on engineInternal?
V8SplitProxyNative.Instance.V8Object_GetNamedProperty(engineInternal, "getStackTrace", value.ptr);

getStackTrace = (V8Object.Handle)value.Decode().PtrOrHandle;

// When I'm done with getStackTrace, is V8Value_Delete enough, or do I need to call any of the V8Entity cleanup methods?
// Is it even legal for me to hold on to getStackTrace for an extended period of time?

[ClearScriptLib]

Hi @AnsisMalins,

First, please understand that ClearScript's native assembly interface is not a public API and could change in future versions.

There are ScriptInvoke and InvokeNoThrow higher up the call stack already, so no need to do them again?

ScriptInvoke is probably OK; that is, nested calls shouldn't be required unless you're interleaving calls into multiple script engines. As for InvokeNoThrow, it depends, as that method assumes that its callback doesn't generate an exception on the native side.

Does overwriting the V8Value release the refcount on engineInternal?

The native version of V8Value is a typical C++ "smart value" class; when an instance is reassigned, it discards its previous contents. However, it's difficult to answer without knowing how your V8Value.Decode method works.

When I'm done with getStackTrace, is V8Value_Delete enough, or do I need to call any of the V8Entity cleanup methods? Is it even legal for me to hold on to getStackTrace for an extended period of time?

Again, it depends on the V8Value.Decode semantics. Is it a wrapper around the native V8Value_Decode? There are some rather intricate subtleties in this area.

Thanks!

[AnsisMalins]

It just calls V8Value_Decode and does nothing else.

[ClearScriptLib]

It just calls V8Value_Decode and does nothing else.

Generally speaking, V8Value_Decode returns data that's valid only as long as the original V8Value remains valid and unmodified. However, there's an exception: As you can see here, V8Value_Decode constructs a new handle if the V8Value is holding a V8 object.

It works that way because the host can only interact with V8 objects via handles, whereas V8Value internally uses a different, .NET-unfriendly means of holding onto such objects.

Therefore, if you call V8Value_Decode on a V8Value that's holding a V8 object, you must remember to destroy the returned handle in addition to deleting the V8Value. To do that, call V8Entity_DestroyHandle.