unmanaged memory and large object heap

  • Thread starter Thread starter cronusf
  • Start date Start date
Hi cronusf!
We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

The problem will be te same... it will be even worser...
Exept if you create your own allocator (and do not use the CRT/OS).

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Hi cronusf!
We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

The problem will be te same... it will be even worser...
Exept if you create your own allocator (and do not use the CRT/OS).

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

Like the article points out, the problem is created by large objects that
grow frequently. Allocate some extra space so you don't have to grow as
often and you shouldn't have any problem. Most dynamic array containers
(std::vector, System::Collections::Generic::List, etc) grow on power-of-2
boundaries, which helps with both performance (less copying the data to a
new location) and reduces fragmentation (free blocks are of commonly used
sizes).

Or use a linked list and stay off of the LOH, if you don't need random
access. Or a hash structure, like System::Collections::Generic::Dictionary
if you need random access but not ordering.
 
We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

Like the article points out, the problem is created by large objects that
grow frequently. Allocate some extra space so you don't have to grow as
often and you shouldn't have any problem. Most dynamic array containers
(std::vector, System::Collections::Generic::List, etc) grow on power-of-2
boundaries, which helps with both performance (less copying the data to a
new location) and reduces fragmentation (free blocks are of commonly used
sizes).

Or use a linked list and stay off of the LOH, if you don't need random
access. Or a hash structure, like System::Collections::Generic::Dictionary
if you need random access but not ordering.
 
Hi cronusf!



The problem will be te same... it will be even worser...
Exept if you create your own allocator (and do not use the CRT/OS).

Why will it be worse? If I use unmanaged arrays, it won't go on the
large object heap, right? It won't go on any managed heap, so it will
be as if I did it in native C++.
 
Hi cronusf!



The problem will be te same... it will be even worser...
Exept if you create your own allocator (and do not use the CRT/OS).

Why will it be worse? If I use unmanaged arrays, it won't go on the
large object heap, right? It won't go on any managed heap, so it will
be as if I did it in native C++.
 
Hi cronusf!
Why will it be worse? If I use unmanaged arrays, it won't go on the
large object heap, right? It won't go on any managed heap, so it will
be as if I did it in native C++.

The LOH has a change to compact it and free some memory, if this is
possible. This is not the case in native heaps.

Greetings
Jochen
 
Hi cronusf!
Why will it be worse? If I use unmanaged arrays, it won't go on the
large object heap, right? It won't go on any managed heap, so it will
be as if I did it in native C++.

The LOH has a change to compact it and free some memory, if this is
possible. This is not the case in native heaps.

Greetings
Jochen
 
Jochen Kalmbach said:
Hi cronusf!


The LOH has a change to compact it and free some memory, if this is
possible. This is not the case in native heaps.

I thought that compaction in the LOH means the same as in Win32 API heaps --
coalescing adjacent free blocks, never moving data.

But definitely yes, the native heap is just as subject to fragmentation as
the LOH.
 
Jochen Kalmbach said:
Hi cronusf!


The LOH has a change to compact it and free some memory, if this is
possible. This is not the case in native heaps.

I thought that compaction in the LOH means the same as in Win32 API heaps --
coalescing adjacent free blocks, never moving data.

But definitely yes, the native heap is just as subject to fragmentation as
the LOH.
 
Back
Top