Memory<byte> from Pointer ... for a possible MemoryMappedViewAccessor extension method

[hopperpl]

Is there a way to implement/generate a Memory<byte> from a pointer? Or is, by definition, Memory<byte> always GC managed memory?

I'm asking the question here, because here are the high-performance code experts.

---

Here is the scenario: I have a 128 GiB memory mapped file, which so far I expose with Span<byte> in ranges (as Span is limited to 2 GiB, but that is fine). I'm not using MemoryMappedViewAccessor, it's not a very useful class, I directly bind to windows API MapViewOfFile() and receive a pointer which I only expose as Span<byte> from a helper class, so this code is as safe and reliable as class MemoryMappedViewAccessor.

This gives a lot of performance advantages, especially as many net core functions accept Span<byte> as input parameter. But there are also some issues with it, as Task cannot uses Span<byte> due to stack location. So far, I use a helper class that transfers a Span by extracting the pointer, and then regenerating that Span inside the Task function. It's hacky, but it works great and the performance gain is extreme. And yes, the Span<byte> originator is pinned correctly as well if needed. And the lifetime of the memory object is ensured as well. None of that is an issue.

But I would prefer if I could use a Memory<byte> instead with valid memory ownership. But I'm not sure if that is even possible. And it would explain why MemoryMappedViewAccessor has no Memory<byte> accessor out of the box.

[ghost]

Tagging subscribers to this area: @GrabYourPitchforks, @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is there a way to implement/generate a Memory<byte> from a pointer? Or is, by definition, Memory<byte> always GC managed memory?

I'm asking the question here, because here are the high-performance code experts.

---

Here is the scenario: I have a 128 GiB memory mapped file, which so far I expose with Span<byte> in ranges (as Span is limited to 2 GiB, but that is fine). I'm not using MemoryMappedViewAccessor, it's not a very useful class, I directly bind to windows API MapViewOfFile() and receive a pointer which I only expose as Span<byte> from a helper class, so this code is as safe and reliable as class MemoryMappedViewAccessor.

This gives a lot of performance advantages, especially as many net core functions accept Span<byte> as input parameter. But there are also some issues with it, as Task cannot uses Span<byte> due to stack location. So far, I use a helper class that transfers a Span by extracting the pointer, and then regenerating that Span inside the Task function. It's hacky, but it works great and the performance gain is extreme. And yes, the Span<byte> originator is pinned correctly as well if needed. And the lifetime of the memory object is ensured as well. None of that is an issue.

But I would prefer if I could use a Memory<byte> instead with valid memory ownership. But I'm not sure if that is even possible. And it would explain why MemoryMappedViewAccessor has no Memory<byte> accessor out of the box.

Author:	hopperpl
Assignees:	-
Labels:	area-System.Memory, untriaged
Milestone:	-

[huoyaoyuan]

You can create your own MemoryManager<T> for wrapping native memory. However, there is still int32 limitation of it.

[hopperpl]

Oh, now I get it.

MemoryManager<T>.CreateMemory does not allocate memory, it returns a Memory<T> object with that length property only. That helps.

The limitation of 2 GiB is not an issue. All Span<T>, Memory<T>, Range, Index are limited that way. The memory mapped file is segmented anyway with each segment below 64 MiB.

If all works out, I will expand MemoryMappedViewAccessor (actually UnmanagedMemoryAccessor) with a "Memory<T> UnmanagedMemoryAccessor.GetMemory(Int64)" function.

[huoyaoyuan]

Related: #37227

[fbrosseau]

Just a detail, but

I'm not using MemoryMappedViewAccessor, it's not a very useful class, I directly bind to windows API MapViewOfFile() and receive a pointer

Unless I am missing something, you are redoing MemoryMappedViewAccessor.SafeMemoryMappedViewHandle.AcquirePointer(ref byte*)

[hopperpl]

Oh, I did not know about that pointer access ability. And I actually didn't expect SafeHandle to expose the base address pointer. Good to know.

[GrabYourPitchforks]

As @huoyaoyuan mentioned, I think the API aspect of this issue is a dupe of #37227. @hopperpl, is there anything else to address from a question perspective, or can we resolve the issue?

[hopperpl]

I have it now working with a Memory accessor.

Thanks to all.