Are [UnmanagedCallersOnly] methods implicitly pinned?

[colejohnson66]

I'm writing a Win32 async I/O method (one with a completion callback). I've managed to pack my GCHandle instances after the NativeOverlapped allocation (roughly the same as System.Threading.Overlapped, but tailored to our use case). This is all good; Running a test that repeatedly calls Collect/WaitForPendingFinalizers, then unpacks the handles works.

We then take that NativeOverlapped* allocation and P/Invoke [Read|Write]FileEx with a delegate* unmanaged[Stdcall]<uint, uint, NativeOverlapped*, void> callback (the LPOVERLAPPED_COMPLETION_ROUTINE lpOverlappedCompletionRoutine parameter)

Is anything necessary to avoid a GC hole with the [UnmanagedCallersOnly] method that the delegate* points to? Or are unmanaged-only methods implicitly pinned?

I ask because I know normal delegates need GC.KeepAlive (except for when it doesn't work: #74966/#104391).

For a simplistic overview, this is what we're doing:

NativeOverlapped* lpOverlapped = overlapped.Pack(<data>);
delegate* unmanaged[Stdcall]<uint, uint, NativeOverlapped* void> lpOverlappedCompletionRoutine = &NativeCallback;

if (!ReadFileEx(..., lpOverlapped, lpOverlappedCompletionRoutine))
{
    overlapped.Free();
    // handle HRESULT
}

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvStdcall)])]
internal static void NativeCallback(uint dwErrorCode, uint dwNumberOfBytesTransferred, NativeOverlapped* lpOverlapped)
{
    MyOverlapped overlapped = MyOverlapped.Unpack(lpOverlapped, out object?[] data);
    // process result
}

[huoyaoyuan]

The calling convention of delegate and corresponding unmanaged method are different. Thus, marshalling delegate into function pointer can require an extra thumb of code. When the delegate is instance method, it also needs to be kept alive for dispatching the target.

[UnmanagedCallersOnly] functions are instead directly compiles into unmanaged-compatible ABI, with no state in closure allowed. Thus the compiled method address can be directly used. However, the ALC still needs to be kept alive to prevent the method code being deallocated.

[colejohnson66]

So we still need to keep the method alive? How?

[huoyaoyuan]

It's usually not a concern if the calling code is in the same assembly.

[AustinWise]

From the blog post originally announcing the feature:

The extra error-prone code for keeping the delegate alive is no longer needed either.

Like @huoyaoyuan mentioned, the one exception you might have to worry about is if your assembly is loaded into an unloadable assembly load context. If you try to call an UnmanagedCallersOnly function after the assembly that defines it has been unloaded, you will crash. You can use the AssemblyLoadContext.Unloading event to clean up callbacks to prevent this crash.

Here is a small program that demonstrates how to do the cleanup:

https://gist.github.com/AustinWise/92f48f2f4c1ce04795599822a7aced89

It calls the Windows function RegisterWaitForSingleObject, passing a UnmanagedCallersOnly as a callback. The code demonstrates loading the library in an unloadable context and how the library can clean up the callback when the unloadable context is being unloaded.

[colejohnson66]

So, if this is in library code that the main program references, there's no worry of it being unloaded? Only if we create an AssemblyLoadContext at runtime?

[AustinWise]

That is correct. If you do not make an unloadable ALC, you don't have to worry about keeping objects alive. Most programs do not use unloadable ALC.