Today I answer the question "what's the deal with the
fixed statement?" in the form of a dialogue, as is my wont. So:
What's the deal with the
As I noted back in 2009, the purpose of the
fixed statement is to tell the garbage collector that your code has made an unsafe, unmanaged pointer into a block of managed memory. Since the garbage collector reserves the right to move that memory around, it is important that you inform the garbage collector that it needs to "pin in place" that memory until you tell it otherwise.
Suppose I am calling unmanaged code from my C# program and I need to pass the code a pointer to a managed array. Eventually control will leave the fixed statement; what if the unmanaged code holds onto that pointer and uses it after the memory becomes unpinned?
Describing what happens in that scenario is not interesting because you are required to not get into that situation in the first place. As the C# specification helpfully points out:
It is the programmer’s responsibility to ensure that pointers created by fixed statements do not survive beyond execution of those statements. For example, when pointers created by fixed statements are passed to external APIs, it is the programmer’s responsibility to ensure that the APIs retain no memory of these pointers.
If you abdicate that responsibility then arbitrarily bad things can happen to your computer; the program can literally do anything that the current process has the right to do, including erasing all your files.
So what if I do that anyway? How do I prevent that undefined behaviour?
If it hurts when you do that then don't do that. Asking "how do I not die from fatally shooting myself?" is a non-starter; don't fatally shoot yourself in the first place if you'd prefer to not die!
No, really, I need to solve this problem! I really do have unmanaged code that captures the pointers I hand to it and dereferences them at an unknown time in the future. What can I do that is responsible?
There are a number of ways to mitigate this terrible situation.
First, you could ensure that control never leaves the fixed block. This is essentially throwing a wrench into the GC performance and also makes it quite difficult to write your program, so I don't recommend it.
Second, you could make a GCHandle object and use it to pin the array in place. It will stay pinned until you free the handle. This will, again, throw a wrench into the garbage collector because there will now be a pinned block that cannot move; the garbage collector will literally have to work around it.1
Third, you could allocate the array out of fixed-in-place unmanaged storage in the first place. For example, you could use
FreeHGlobal to do your own memory management. That's what I'd probably do if faced with this unfortunate situation.
Next time on FAIC: What I did on my Kauai vacation.
- To mitigate the performance problem you could make the array really big. Large arrays go on a large object heap, which is not compacted like the regular heap is, so the penalty of having an immovable block in the middle of the heap goes away. Of course, making an array far, far larger than it needs to be in order to solve a performance problem is likely to cause performance problems of its own. And also, the behaviour of the large object heap is an implementation detail subject to change at any time, not a contract you can rely on. This is, again, probably a bad idea, but it will work. ↩