Are method locals "fixed"?

[colejohnson66]

I'm trying to write some convenience wrappers around CsWin32, and I'm hitting an issue with reference/pointer conversion. Are method local variables considered "fixed"/"GC safe" in the below?

void MethodA(Span<byte> buffer)
{
    NativeOverlapped overlapped = new();
    // ...
    UseOverlapped(buffer, ref overlapped);
}

void MethodB(Span<byte> buffer, scoped ref NativeOverlapped lpOverlapped)
{
    // CsWin32 wrapper around Win32's ReadFile
    bool result = PInvoke.ReadFile(handle, buffer, null, (NativeOverlapped*)Unsafe.AsPointer(ref lpOverlapped);
    // ...
}

Or does MethodB have to be written as this:

void MethodB(Span<byte> buffer, scoped ref NativeOverlapped lpOverlapped)
{
    bool result;
    fixed (NativeOverlapped* lpOverlappedLocal = &lpOverlapped)
    {
        result = PInvoke.ReadFile(handle, buffer, null, lpOverlappedLocal);
    }
    // ...
}

It's my understanding that things on the stack are "rooted" by their nature, so Unsafe.AsPointer should be safe, but I'd like confirmation.

[EgorBo]

While it is safe in this case, it is generally recommended to avoid relying on such details and express intentions directly via fixed. Unsafe.AsPointer is one of the most dangerous API and, sadly, too often introduces so called gc holes.

[colejohnson66]

Fair. It's just that the logic is being extracted out of MethodA and fixed is not needed to take the address of the local; only when it's passed down is it necessary. I’ll refrain from Unsafe.AsPointer for safety, however.

[huoyaoyuan]

I'm interested of the implementation behind. What's the major difference of fix pointer? I thought it's GC info reported from JIT to GC.
If the fixed target isn't in GC heap, will GC simply ignore it while doing scanning?

[tannergooding]

At the high level: When the GC runs it will look at the pinned value (same as it already would look for any ref T you have) and determine if it could live in the heap or not. If it could not live in the heap, then it simply ignores the value and continues on.

Thus, by having a ref T in the first place, you're already paying for some amount of GC tracking consideration. The pinning itself is cheap (it just entails storing the reference to the stack) and so unless you're making an incredibly trivial call in a tight loop it will essentially appear as noise in the overall context of the program. -- If you have such an incredibly trivial call in a tight loop, you likely need to consider the fact that the P/Invoke transition itself is several orders of magnitude more expensive than the pinning, as is the general cost of the call, and any potential for argument passing/returning which may themselves entail stack spilling due to ABI requirements (even in C/C++).

[tannergooding]

The JIT can also elide some cases of pinning when it knows the value being pinned is already fixed and in the future may even be able to avoid the spill by just tracking that the register contains a pinned value instead.

So there's really no reason to not pin and its much easier to just expose an overload that takes T* if you want to be explicit and guarantee some code paths avoid pinning.