Pinned ptr vs native alloc

  • Thread starter Thread starter -DG-
  • Start date Start date
D

-DG-

I'm still trying to figure out some of the nuances of access to legacy
Win32 DLLs. I need to alloc buffers to be used by the Win32 DLLs. I
know that pinning a managed pointer can lead to framentation, but I
don't see an alternative. Is there an easy way to generate a call to
native malloc()? Doesn't this also fragment memory?

(I'll be using C++/CLI, if that matters)
 
Is there an easy way to generate a call to native malloc()?
#inlucde <malloc.h>

and call malloc as you always did; The compiler and the linker generate the
necessary P/Invoke functions automatically for you.
Doesn't this also fragment memory?
Click to expand...
Yes, but the malloc-heap is better prepared for fragmentations
I'm still trying to figure out some of the nuances of access to legacy
Win32 DLLs. I need to alloc buffers to be used by the Win32 DLLs. I
know that pinning a managed pointer can lead to framentation, but I
don't see an alternative.
Click to expand...
Allocation memory on other heaps can indeed be an alternative - especially
for pinning small objects, especiall if the pinning would span a blocking
call.
Here is the alternative:
1) Allocate unmanaged memory via one of the various heaps
2) If necessary, copy the managed object's state via Marshal::Copy to the
unmanaged memory
3) Call the native function
4) If necessary, copy the managed object's state via Marshal::Copy to the
unmanaged memory

Also notice, managed objects with a size > 83KB + 8 Bytes object header will
end up on the managed "large object heap" which uses other heuristics. This
heap also had its problems in earlier versions of .NET , but when it comes
to pinning, it may be an opion.

Marcus Heege
 
Here is the alternative:
1) Allocate unmanaged memory via one of the various heaps
2) If necessary, copy the managed object's state via Marshal::Copy to the
unmanaged memory
3) Call the native function
4) If necessary, copy the managed object's state via Marshal::Copy to the
unmanaged memory
Click to expand...

Thanks, Marcus. Very helpful. I'm thinking that in 4) above, you
probably meant the reverse though, right? After the call to the
native function, you'd copy memory back from 'unmanaged' to 'managed'
for use within .NET code.

I've seen general overviews describing new CLI functions, but haven't
seen much example code. I'm missing perspective and details on how to
implement the bridge to native code.
Also notice, managed objects with a size > 83KB + 8 Bytes object header will
end up on the managed "large object heap" which uses other heuristics.
Click to expand...

I had no idea that there was a magic number involved. An odd one at
that.

I've hit another snag: "'#pragma unmanaged' can only be used at
global or namespace scope" (occurs when trying to compile an unmanaged
function within a class). I was hoping to build the interface to the
low-level DLL within a class. Looks like this will be almost as messy
as my old managed extensions wrappers.
 
You are right, my explanations had a copy and paste bug. Here is the
corrected one:
 
Back
Top