GC does not release mem of large objects completly

[WinstonSmith]

Hello everyone,

I got a problem about GC when creating large fields (some MB), set reference
to null and call GC.Collect. Not all virtual mem is released. Situation
improved in .net 1.1 but not in a full satisfying way.

Has anyone a solution to handle large object in safe code?
(Unsafe mem management works, but has serious disadvantages on
serialization.)

Thanks in advance

[Chris Lyon [MSFT]]

Hi Winston

Objects in the large object heap are put in generation 2, so if you want to
force a collection of large objects, make sure you run Collect with no
parameters, or with GC.MaxGeneration as a parameter.

The CLR uses memory internally, so even though you've just run GC.Collect,
there is some memory not considered garbage that the runtime uses.

For example, if you write an app, and all it does is print
GC.GetTotalMemory to the console twice, then GC.Collect, then
GetTotalmemory again, you'll notice memory not freed.

Hope that helps
-Chris
--------------------

From: "WinstonSmith" <ma***********@gmx.de>
Subject: GC does not release mem of large objects completly
Date: Tue, 29 Jul 2003 17:46:27 +0200
Lines: 13
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <uf**************@TK2MSFTNGP12.phx.gbl>
Newsgroups: microsoft.public.dotnet.general
NNTP-Posting-Host: lighttrans.tip-jena.de 217.17.193.199
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP12.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.general:102716
X-Tomcat-NG: microsoft.public.dotnet.general

Hello everyone,

I got a problem about GC when creating large fields (some MB), set referenceto null and call GC.Collect. Not all virtual mem is released. Situation
improved in .net 1.1 but not in a full satisfying way.

Has anyone a solution to handle large object in safe code?
(Unsafe mem management works, but has serious disadvantages on
serialization.)

Thanks in advance

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
originated.

[Willy Denoyette [MVP]]

Chris,

As far as I know large objects (>85K - CLR v1.1) are directly stored in the large object heap not the Gen2 heap.
The problem with the large object heap is that while he can get collected, he never gets compacted.
Allocations require contiguous blocks of memory, when the allocation scheme is irregular, allocated memory tend to grow, this seems
to be one of the problems the GC can't handle yet.

Willy.

"Chris Lyon [MSFT]" wrote:
|| Hi Winston
||
|| Objects in the large object heap are put in generation 2, so if you
|| want to force a collection of large objects, make sure you run
|| Collect with no parameters, or with GC.MaxGeneration as a parameter.
||
|| The CLR uses memory internally, so even though you've just run
|| GC.Collect, there is some memory not considered garbage that the
|| runtime uses.
||
|| For example, if you write an app, and all it does is print
|| GC.GetTotalMemory to the console twice, then GC.Collect, then
|| GetTotalmemory again, you'll notice memory not freed.
||
|| Hope that helps
|| -Chris
||

[Chris Lyon [MSFT]]

Hi Willy,

That's right. I guess I wasn't clear in my response. Large objects are in the large object heap, but are only collected at the same time as gen 2.

You are correct, the large object heap does not get compacted.

Matthias, this is not a flaw in the GC, rather a tradeoff, since the performance hit for compacting large allocations outweighs the benefit of coniguous blocks.
Hope that's clearer :)
-Chris

--------------------

From: "WinstonSmith" <ma***********@gmx.de>
References: <uf**************@TK2MSFTNGP12.phx.gbl> <Lu**************@cpmsftngxa06.phx.gbl> <ee**************@tk2msftngp13.phx.gbl>
Subject: Re: GC does not release mem of large objects completly
Date: Thu, 31 Jul 2003 10:04:19 +0200
Lines: 42
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <#x**************@TK2MSFTNGP09.phx.gbl>
Newsgroups: microsoft.public.dotnet.general
NNTP-Posting-Host: lighttrans.tip-jena.de 217.17.193.199
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP09.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.general:102963
X-Tomcat-NG: microsoft.public.dotnet.general

Thank you for your help...
So its an design flaw of .net? Does anyone know, if it's going to be fixed
in later releases?

Matthias

"Willy Denoyette [MVP]" <wi*************@skynet.be> schrieb im Newsbeitrag
news:ee**************@tk2msftngp13.phx.gbl...

Chris,

As far as I know large objects (>85K - CLR v1.1) are directly stored in

the large object heap not the Gen2 heap.

The problem with the large object heap is that while he can get collected,

he never gets compacted.

Allocations require contiguous blocks of memory, when the allocation

scheme is irregular, allocated memory tend to grow, this seems

to be one of the problems the GC can't handle yet.

Willy.

"Chris Lyon [MSFT]" wrote:
|| Hi Winston
||
|| Objects in the large object heap are put in generation 2, so if you
|| want to force a collection of large objects, make sure you run
|| Collect with no parameters, or with GC.MaxGeneration as a parameter.
||
|| The CLR uses memory internally, so even though you've just run
|| GC.Collect, there is some memory not considered garbage that the
|| runtime uses.
||
|| For example, if you write an app, and all it does is print
|| GC.GetTotalMemory to the console twice, then GC.Collect, then
|| GetTotalmemory again, you'll notice memory not freed.
||
|| Hope that helps
|| -Chris
||

--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.