I skimmed the code a little and did a few Github searches on it and it looks like the only unsafe blocks of code are in the core data bus. It's not entirely clear why it was done that way, as the CPU itself is using managed arrays to represent memory. Perhaps it was necessary for speed, as it seems primarily concerned with loading the executables that are to be emulated.
Otherwise, everything looks statically allocated. So there should be no GC collections at all.
I use it with DeviceIOControl for interoperating with a driver.
I didn't learn by following someone's example, in my case, I have to work with so many different structs in a high performance use case that I took the time to re-learn pointers. (Haven't used them in years.)
1: Memory is allocated using new byte[bufferSize]
2: That byte[] is pinned to a byte* or void* via fixed
3: The pointer is passed to DeviceIOControl
4: Traditional c-style typecasting inside of fixed
5: Traditional GC cleans up your byte[]. This avoids problems with managed programs that allocate lots of native memory.
I don't know how to use pointers with Span<T>...
BUT: I do similar things with ArraySegment<byte[]>. All that's needed is pointer arithmetic:
ArraySegment<byte> arraySegment = ...
fixed (byte* dataArrayPtr = arraySegment.Array)
{
var dataPtr = dataArrayPtr + arraySegment.Offset;
var ptr = (SomeStruct*)dataPtr;
}
I only mention it because I'm not entirely clear on what is going on or how it works (largely because I tend to only be able to learn things by doing them, which is my own issue, not your failure to describe it), but after reading the docs on MemoryMappedFiles, I wonder if it's something that could be useful to you.
Otherwise, everything looks statically allocated. So there should be no GC collections at all.