stop the GC

  • Thread starter Thread starter Vadym Stetsyak
  • Start date Start date
V

Vadym Stetsyak

Hi there!

Is there any way how can I stop garbage collection for a period of time.

Lets say, I have a form. Before form load I pause the GC and when the form
is shown resume GC
 
I don't think so.
What would happen if one app stops GC and never starts it again?
 
hmm, AFAIK Garbage Collector operates in the managed heap and every .NET app
has its own heap, so I can assume that every heap has its own collector.



Miha Markic said:
I don't think so.
What would happen if one app stops GC and never starts it again?

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Vadym Stetsyak said:
Hi there!

Is there any way how can I stop garbage collection for a period of time.

Lets say, I have a form. Before form load I pause the GC and when the form
is shown resume GC
 
One app thats leaking alot of memory :D


Miha Markic said:
I don't think so.
What would happen if one app stops GC and never starts it again?

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Vadym Stetsyak said:
Hi there!

Is there any way how can I stop garbage collection for a period of time.

Lets say, I have a form. Before form load I pause the GC and when the form
is shown resume GC
 
Hi,

there is only one managed heap AFAIK.
Ask yourself, if every application has it's own heap, why would the garbage
collector need one ?
They are one and the same. If you are creating objects, memory comes from
the managed heap.
If you stop using those objects, the garbage collector reclaims this memory
(eventually).

BTW, why would you want to stop the garbage collector while creating the
form ?
Have you ever noticed the presence of the garbage collector (with regard to
performance, memory usage is another issue) ?

Greetings,

Bram.

Vadym Stetsyak said:
hmm, AFAIK Garbage Collector operates in the managed heap and every .NET app
has its own heap, so I can assume that every heap has its own collector.



Miha Markic said:
I don't think so.
What would happen if one app stops GC and never starts it again?

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Vadym Stetsyak said:
Hi there!

Is there any way how can I stop garbage collection for a period of time.

Lets say, I have a form. Before form load I pause the GC and when the form
is shown resume GC
 
Hi Barn,
What do you mean "there is only one managed heap"?
What if two application run in different processes how do you expect them to
sare the same memory.
In a 32 bit machine a process can access 4GB flat address space. Normaly
windows application can use 2GB of them so if my all .NET application share
2GB or 4GB how many application can I run at the same time?
Of course using *file mapping* technique one can share a lot more memory
between precesses, but I don't thing this is the way GC works.
It might be (I'm not sure) that all application domains in the same process
to share the same managed heap. But it is for sure that not all .NET
application in the system share the same heap.

However for the original post; I don't thing you are able to stop the GC and
I don't see any reason to do that.
If you have any problems it might be something wrong with your application.
Would you give more information about your problem if you have any?
If you are concerned about performance don't be. IMHO GC is well optimized
and in normal conditions you shouldn't feel its exisitence.

B\rgds
100

Bram said:
Hi,

there is only one managed heap AFAIK.
Ask yourself, if every application has it's own heap, why would the garbage
collector need one ?
They are one and the same. If you are creating objects, memory comes from
the managed heap.
If you stop using those objects, the garbage collector reclaims this memory
(eventually).

BTW, why would you want to stop the garbage collector while creating the
form ?
Have you ever noticed the presence of the garbage collector (with regard to
performance, memory usage is another issue) ?

Greetings,

Bram.

Vadym Stetsyak said:
hmm, AFAIK Garbage Collector operates in the managed heap and every .NET app
has its own heap, so I can assume that every heap has its own collector.



Miha Markic said:
I don't think so.
What would happen if one app stops GC and never starts it again?

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Hi there!

Is there any way how can I stop garbage collection for a period of time.

Lets say, I have a form. Before form load I pause the GC and when
the
form
is shown resume GC
 
My form involves great number of references, and the number of weak
references is rather big, so when the form is loading GC is also working
thus slowing down the form load process...
there is only one managed heap AFAIK.
Ask yourself, if every application has it's own heap, why would the garbage
collector need one ?
They are one and the same. If you are creating objects, memory comes from
the managed heap.
If you stop using those objects, the garbage collector reclaims this memory
(eventually).

AFAIK every .NET application starts CLR host, which resides in the windows
process. And therefore memory of this process is shared only for tha
appdomains in that process. I can hardly imagine the GC, that is looking in
the memory of other processes and builds the graph of objects currently in
the heap.
 
Hi,

Stoitcho Goutsev (100) said:
Hi Barn,
What do you mean "there is only one managed heap"?

I was referring to a single process. Every .NET application process has its
own and only one managed heap. Two different processes won't share the same
heap, as you also mentioned.
Two or more application domains will use the same heap, as memory is managed
and no single application can corrupt the heap and take all the other
applications down with it. That's how things might be in the future. If we
now launch a .NET application, a new .NET runtime engine is created to run
the app. That's why every (.NET) process takes at least 8 MB of memory or
even more. In the future, I guess, two or more applications might get
loaded into the same runtime engine (different domain though) when they (MS)
change the loader. This way they can share the framework assemblies to
preserve memory (a different way of code sharing). But that's all a guess.
Anybody real facts about this ?

Sorry for any confusion.
Greetings,

Bram.
What if two application run in different processes how do you expect them to
sare the same memory.
In a 32 bit machine a process can access 4GB flat address space. Normaly
windows application can use 2GB of them so if my all .NET application share
2GB or 4GB how many application can I run at the same time?
Of course using *file mapping* technique one can share a lot more memory
between precesses, but I don't thing this is the way GC works.
It might be (I'm not sure) that all application domains in the same process
to share the same managed heap. But it is for sure that not all .NET
application in the system share the same heap.

However for the original post; I don't thing you are able to stop the GC and
I don't see any reason to do that.
If you have any problems it might be something wrong with your application.
Would you give more information about your problem if you have any?
If you are concerned about performance don't be. IMHO GC is well optimized
and in normal conditions you shouldn't feel its exisitence.

B\rgds
100

Bram said:
Hi,

there is only one managed heap AFAIK.
Ask yourself, if every application has it's own heap, why would the garbage
collector need one ?
They are one and the same. If you are creating objects, memory comes from
the managed heap.
If you stop using those objects, the garbage collector reclaims this memory
(eventually).

BTW, why would you want to stop the garbage collector while creating the
form ?
Have you ever noticed the presence of the garbage collector (with regard to
performance, memory usage is another issue) ?

Greetings,

Bram.

Vadym Stetsyak said:
hmm, AFAIK Garbage Collector operates in the managed heap and every
..NET
app
has its own heap, so I can assume that every heap has its own collector.



"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
I don't think so.
What would happen if one app stops GC and never starts it again?

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Hi there!

Is there any way how can I stop garbage collection for a period of time.

Lets say, I have a form. Before form load I pause the GC and when the
form
is shown resume GC
 
Hi,

Vadym Stetsyak said:
My form involves great number of references, and the number of weak
references is rather big, so when the form is loading GC is also working
thus slowing down the form load process...

Are you sure the GC is running when a form is being loaded ? Could be.
They might trigger a garbage collection when you are about to do something
intensive, like loading a form, so you don't notice the collection.
Brilliant cover up.
Don't think you'll ever notice the collector running, or not in any normal
application. Might be noticeable in some real-time applications which use a
lot of memory.
BTW, what is your memory usage when the form has been loaded ?

Greetings,

Bram
 
Hi Bram,
All application domains in the same process use the same mamory that is
true. Because they are managed (checked when compiled by the JITter) they
won't write in the memory addresses they are not supposed to write. However
it doesn't imply that they use the same managed heap as a structure. The
could use one heap of course. What I'm saing is that I haven't read
(actually I haven't ask my self that question) whether the heap is one or
each domain has its own. And I thing it is not important since application
domains cannot share memory.
Right now you cannot start two application in the same process using windows
loader, but you can start different application in the same process as a new
application domain from within the process (from application domain already
running in the process) Then they will share the same framework assemblies
because those assembies are loaded application neutral.

B\rgds
100

Bram said:
Hi,

Stoitcho Goutsev (100) said:
Hi Barn,
What do you mean "there is only one managed heap"?

I was referring to a single process. Every .NET application process has its
own and only one managed heap. Two different processes won't share the same
heap, as you also mentioned.
Two or more application domains will use the same heap, as memory is managed
and no single application can corrupt the heap and take all the other
applications down with it. That's how things might be in the future. If we
now launch a .NET application, a new .NET runtime engine is created to run
the app. That's why every (.NET) process takes at least 8 MB of memory or
even more. In the future, I guess, two or more applications might get
loaded into the same runtime engine (different domain though) when they (MS)
change the loader. This way they can share the framework assemblies to
preserve memory (a different way of code sharing). But that's all a guess.
Anybody real facts about this ?

Sorry for any confusion.
Greetings,

Bram.
What if two application run in different processes how do you expect
them
to
sare the same memory.
In a 32 bit machine a process can access 4GB flat address space. Normaly
windows application can use 2GB of them so if my all .NET application share
2GB or 4GB how many application can I run at the same time?
Of course using *file mapping* technique one can share a lot more memory
between precesses, but I don't thing this is the way GC works.
It might be (I'm not sure) that all application domains in the same process
to share the same managed heap. But it is for sure that not all .NET
application in the system share the same heap.

However for the original post; I don't thing you are able to stop the GC and
I don't see any reason to do that.
If you have any problems it might be something wrong with your application.
Would you give more information about your problem if you have any?
If you are concerned about performance don't be. IMHO GC is well optimized
and in normal conditions you shouldn't feel its exisitence.

B\rgds
100

Bram said:
Hi,

there is only one managed heap AFAIK.
Ask yourself, if every application has it's own heap, why would the garbage
collector need one ?
They are one and the same. If you are creating objects, memory comes from
the managed heap.
If you stop using those objects, the garbage collector reclaims this memory
(eventually).

BTW, why would you want to stop the garbage collector while creating the
form ?
Have you ever noticed the presence of the garbage collector (with
regard
to
performance, memory usage is another issue) ?

Greetings,

Bram.

hmm, AFAIK Garbage Collector operates in the managed heap and every .NET
app
has its own heap, so I can assume that every heap has its own collector.



"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
I don't think so.
What would happen if one app stops GC and never starts it again?

--
Miha Markic [MVP C#] - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

Hi there!

Is there any way how can I stop garbage collection for a period of
time.

Lets say, I have a form. Before form load I pause the GC and
when
the
form
is shown resume GC
 
I'm studying my application with the profiling tools, so there is no doubt
whos taking processor time.

Consumed memory is about 200 Mb.
 
Vadym,
This sounds like a place I would consider calling GC.Collect, followed by
GC.WaitForPendingFinalizers & a second GC.Collect before loading the form,
to help ensure that the heap was nice & clean, thus minimizing the chance
that the GC would need to do a collection while the form was loading.

Not sure if it will help per se, but its a thought ;-)


Also: Every thing you wanted to know about the GC but were afraid to ask:

http://msdn.microsoft.com/msdnmag/issues/1100/gci/
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/

Hope this helps
Jay


Hope this helps
Jay
 
Back
Top