Re: Garbage collectable pinned arrays!

The array is automatically allocated on the heap once it exceeds
a certain size and thu's becomes "pinned", because the heap is
never compacted and all addresses are absolute.

Arrays that exceed a certain size (85Kb currently), are moved to the
Large Object Heap, but they aren't pinned by this. The LOH is not
compacted, but that doesn't mean that the objects cannot get
collected.

All objects on the LOH are pinned at all times, by the nature of the heap
(non-compacting).

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.



.

Relevant Pages

  • Re: outofmemoryException
    ... you're allocating huge gobs of memory and fragment the LOH, ... Also, the LOH heap does ... What do the other perf counters tell you? ... > I am accessing Blob from Oracle database using> OleDbDataReader,ExecuteReader method.I am getting an outofMemoryException> when blob keeps on accessing and total size of all the blobs exceeds 1 GB. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: difference between private static and public static.
    ... so they are NEVER on the GC heap. ... The GC and the JIT for instance are completely different, but you are right, it doesn't say it's on the GC heap, while actually it is, be it on the LOH and not on the Generational heap. ... Now, I've done some more research to find out where static fields, holding references to boxed value types, actually have their roots. ... What's important is 3), here the static field reference 's', pointing to the boxed instance of S, is on the LOH. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: outofmemoryException
    ... I have dumped my application's managed heap using WinDBG(scenario:with 10 ... numbers of 16MB LongRaw data). ... exception.Pretends memory leak happens in the native memory. ... > you're allocating huge gobs of memory and fragment the LOH, ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Memory leak because of fragmented Large Object Heap?
    ... the article says "never compacted" for LOH ... > while you right in saying the LOH is never compacting doesn't mean memory ... > this heap does never get freed. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Memory leak because of fragmented Large Object Heap?
    ... Also when they say "never compacted", that doesn't mean that the LOH isn't ... and will tend to show some bloat over time. ... So although the large object heap will develop slack space which you won't ...
    (microsoft.public.dotnet.framework.performance)