Re: Garbage collectable pinned arrays!

"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message news:%23bjU84abIHA.5400@xxxxxxxxxxxxxxxxxxxxxxx
This is not what pinned means in this context. The objects on the LOH
(all version of the CLR) are at a fixed address for their life time,
but that doesn't mean they are pinned. Pinning is an explicit action

Ok, but then they don't require pinning. In any case they inherently have the fixed address which requires pinning to obtain for normal objects.


As I said before, pinning is an action performed by the Interop layer *when the GC initiates a scan, and it's not done by means of a call to GCHandle.Alloc. You only need to pin "explicitely" when you are passing an object to unmanaged code and you need to keep the object alive and at fixed location after the PInvoke call returned, during the call the PInvoke layer takes care of eventual pinning.
Also, you keep ignoring my remark that the fact that addresses of *Large* objects are fixed is a convenience of the current version of the CLR, nothing stops MS from changing this.


It would be useful to request that a particular buffer not be
subject to relocation by the GC. Probably the easiest way to do
this would be to place it in the LOH. The OLE task allocator or
HGlobal allocator, both of which are already exposed by the Marshal
class in a typeless way, would be other options. It could be as
simple as adding a T[] Marshal.AllocCoTaskMem<T>(int elementCount)
override.

But now you are allocating from the unmanaged heap (COM heap or CRT
heap or whatever). So now you will incur the costs of copying back
and forth, again this depends on the semantics, but might be a
solution when you need to pass large data chunks to unmanaged land.

Why? .NET could create a proper array descriptor storing the metadata alongside and access it directly.


Where? outside of the GC heap? Who's going to "manage" these objects then? As you may know, there are other cheap means to pass fixed buffers to managed code.

Willy.


.

Relevant Pages

  • Re: Garbage collectable pinned arrays!
    ... LOH (all version of the CLR) are at a fixed address for their life ... but then they don't require pinning. ... from the LOH, OLE task allocator, etc, etc. ... But now you are allocating from the unmanaged heap (COM heap or CRT ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: When do I need to pin?
    ... Then pinning the byte array is not necessary because CLR may do it for us. ... The sample code is quoted from http://www.pinvoke.net: ... Will it pin for us or not? ...
    (microsoft.public.dotnet.framework.interop)
Loading