Visual Cobol Memory Issues

[Migrated content. Thread originally posted on 15 March 2012]

Hi All,

When running my visual cobol project in a live environment noticed the memory allocation just goes up and up and up.

So came across :-

msdn.microsoft.com/.../xe0c2357.aspx

Which I have turned into the following cobol code:-

01 ls-count1 binary-double.
01 ls-count2 binary-double.
01 ls-boo condition-value value true.

set ls-boo to false
invoke type "System.GC"::"GetTotalMemory"(ls-boo) returning ls-count1

invoke type "System.GC"::"Collect"()

set ls-boo to true
invoke type "System.GC"::"GetTotalMemory"(ls-boo) returning ls-count2

So my question is "Am I ok to put this into the Closing event of every form in my project"?

If any one could pls advise.

Many thanks

Neil.

Hi Neil,
Just to set the scene, I'm assuming that this is a COBOL for .Net WinForms application.

In .Net applications, memory management is a little more complex than in a traditional application using deterministic memory management. The CLR (the code that runs the .Net application) will happily make the best possible use of all available memory to improve the performance of your application. The consequence of this is that it is not necessarily a problem that memory usage goes up. It might just be the framework trying to keep as much of your application in memory as possible so that it can re-execute it as quickly as possible.
Once the physical memory of the machine is all in use, then the framework will work harder to reclaim memory.

This process is called garbage collection, goes on automatically, and Microsoft's recommendation is not to try to influence its behaviour. Adding in your Collect calls will simply push the garbage collector to act sooner than it would otherwise. It may or may not reclaim any unused memory, and the best you can hope for is that it releases some memory sooner that it would have released anyway.

Having said all of that, it is also possible for .Net applications to leak memory, in which case their memory usage will climb slowly and steadily. In this case, garbage collection will not help you at all. The best approach is to locate and fix the leak. Microsoft have a number of resources on the subject:
SOS.dll (SOS Debugging Extension)
Identify And Prevent Memory Leaks In Managed Code
Advanced Debugging (Codeproject)
Memory Misconceptions (RedHat)

Please note that Micro Focus are not responsible for external content.

John

[Migrated content. Thread originally posted on 15 March 2012]

Hi All,

When running my visual cobol project in a live environment noticed the memory allocation just goes up and up and up.

So came across :-

msdn.microsoft.com/.../xe0c2357.aspx

Which I have turned into the following cobol code:-

01 ls-count1 binary-double.
01 ls-count2 binary-double.
01 ls-boo condition-value value true.

set ls-boo to false
invoke type "System.GC"::"GetTotalMemory"(ls-boo) returning ls-count1

invoke type "System.GC"::"Collect"()

set ls-boo to true
invoke type "System.GC"::"GetTotalMemory"(ls-boo) returning ls-count2

So my question is "Am I ok to put this into the Closing event of every form in my project"?

If any one could pls advise.

Many thanks

Neil.

Hi Neil,
Just to set the scene, I'm assuming that this is a COBOL for .Net WinForms application.

In .Net applications, memory management is a little more complex than in a traditional application using deterministic memory management. The CLR (the code that runs the .Net application) will happily make the best possible use of all available memory to improve the performance of your application. The consequence of this is that it is not necessarily a problem that memory usage goes up. It might just be the framework trying to keep as much of your application in memory as possible so that it can re-execute it as quickly as possible.
Once the physical memory of the machine is all in use, then the framework will work harder to reclaim memory.

This process is called garbage collection, goes on automatically, and Microsoft's recommendation is not to try to influence its behaviour. Adding in your Collect calls will simply push the garbage collector to act sooner than it would otherwise. It may or may not reclaim any unused memory, and the best you can hope for is that it releases some memory sooner that it would have released anyway.

Having said all of that, it is also possible for .Net applications to leak memory, in which case their memory usage will climb slowly and steadily. In this case, garbage collection will not help you at all. The best approach is to locate and fix the leak. Microsoft have a number of resources on the subject:
SOS.dll (SOS Debugging Extension)
Identify And Prevent Memory Leaks In Managed Code
Advanced Debugging (Codeproject)
Memory Misconceptions (RedHat)

Please note that Micro Focus are not responsible for external content.

John

[Migrated content. Thread originally posted on 15 March 2012]

Hi All,

When running my visual cobol project in a live environment noticed the memory allocation just goes up and up and up.

So came across :-

msdn.microsoft.com/.../xe0c2357.aspx

Which I have turned into the following cobol code:-

01 ls-count1 binary-double.
01 ls-count2 binary-double.
01 ls-boo condition-value value true.

set ls-boo to false
invoke type "System.GC"::"GetTotalMemory"(ls-boo) returning ls-count1

invoke type "System.GC"::"Collect"()

set ls-boo to true
invoke type "System.GC"::"GetTotalMemory"(ls-boo) returning ls-count2

So my question is "Am I ok to put this into the Closing event of every form in my project"?

If any one could pls advise.

Many thanks

Neil.

Hi Neil,
Just to set the scene, I'm assuming that this is a COBOL for .Net WinForms application.

In .Net applications, memory management is a little more complex than in a traditional application using deterministic memory management. The CLR (the code that runs the .Net application) will happily make the best possible use of all available memory to improve the performance of your application. The consequence of this is that it is not necessarily a problem that memory usage goes up. It might just be the framework trying to keep as much of your application in memory as possible so that it can re-execute it as quickly as possible.
Once the physical memory of the machine is all in use, then the framework will work harder to reclaim memory.

This process is called garbage collection, goes on automatically, and Microsoft's recommendation is not to try to influence its behaviour. Adding in your Collect calls will simply push the garbage collector to act sooner than it would otherwise. It may or may not reclaim any unused memory, and the best you can hope for is that it releases some memory sooner that it would have released anyway.

Having said all of that, it is also possible for .Net applications to leak memory, in which case their memory usage will climb slowly and steadily. In this case, garbage collection will not help you at all. The best approach is to locate and fix the leak. Microsoft have a number of resources on the subject:
SOS.dll (SOS Debugging Extension)
Identify And Prevent Memory Leaks In Managed Code
Advanced Debugging (Codeproject)
Memory Misconceptions (RedHat)

Please note that Micro Focus are not responsible for external content.

John