Garbage Collection & Creating Class Instances

[Benjamin Lukner]

Hi!

I had a problem for several days and now found out what it is caused by:

When calling Sub New of a class under XP, on a specific line (getting IP
address) the procedure was left immediately without raising an error.
Break Points in code lines after the "x = new y" were ignored. Stepping
through the code opens a message box on that line:

"There is not source code available for the current location."

The cause:

The program is a terminal emulation running in two versions for XP and
CE but sharing most of the code. When the connection is closed the
program restarts internally. Under CE the memory runs full because the
garbage collection doesn't clean up. So I added:

GC.Collect()
GC.GetTotalMemory(True)
GC.WaitForPendingFinalizers()

This runs perfectly under CE. But under XP it seems to dispose objects
that are created afterwards, _while_ they are created!

I solved the problem by detecting if it is a CE device and calling GC.*
only there.


Does anyone know more about this behaviour?


Kind regards,

Benjamin Lukner

 

[Jonathan Allen]

Do you have the problem on real CE machines, or just the emulator?

 

[David McNamee]

Under CE the memory runs full because the garbage collection doesn't clean
up. So I added:

GC.Collect()
GC.GetTotalMemory(True)
GC.WaitForPendingFinalizers()

This runs perfectly under CE. But under XP it seems to dispose objects
that are created afterwards, _while_ they are created!

Calling GC.Collect() is usually discouraged except under a few extreme
circumstances. You may want to recompile your app for the desktop so you
can run the CLR Allocation Profiler and watch what your objects are doing.
A gc will happen under memory pressure, but you want to make sure your
objects are actually collectible. Be careful of finalizers and global
objects - those are things that prolong . You may want to consider
explicitly setting objects to null (VB:Nothing) as soon as you are done with
them. Also consider if you actually need all those object instances.
Depending on what you are doing, you might be able to re-engineer certain
things into static (VB:Shared) methods.

There is an MSDN article that discusses using CLR Profiler here:
http://msdn.microsoft.com/msdnmag/issues/05/01/MemoryOptimization/default.aspx

 

[Benjamin Lukner]

Do you have the problem on real CE machines, or just the emulator?

The problem with the garbage collection not cleaning up occurs on all
Pocket PC 2002/2003/CE/CE.Net devices I have. I spent much time on
tuning all classes. Now every class has a Shutdown() procedure I
explicitely call where all objects are cleaned up, disposed if possible
and set to nothing. Anyway GC does not clean up. After 300 to 500
restarts (if the terminal emulation has no auto login and gets kicked
once per minute by the server) the Pocket PC memory is full and the
OutOfMemory exception is raised. Calling GC.Collect on every restart
works very fine on CE.

On XP the call causes unpredictable behaviour. But only since I added
some UDP code to my project. Before it worked fine for over a year!

I think I'll only call GC.Collect on CE. Without that call the memory
usage stays quite the same under XP. Though the same source code is used
for both platforms but compiled as Win32 and Pocket PC Application...

Kind regards,

Benjamin Lukner

 

[Benjamin Lukner]

Calling GC.Collect() is usually discouraged except under a few extreme
circumstances. You may want to recompile your app for the desktop so you
can run the CLR Allocation Profiler and watch what your objects are doing.

Hi!

thanks for the answer. I'll have a look at the article.

But as I've written in my other posting I already compile the program in
two versions with almost the same source code (differences only in
declaration of the API calls and a dummy for CreateControl() under CE).
The problem only occurs with the CE version where some dozen kb aren't
released on every (internal) restart. With GC.Collect I restarted my
emulation 3000 times _without any_ increasing of memory usage

Maybe there'll be a profiler for CE in the future...

Kind regards,

Benjamin Lukner