fbpx
Welcome, Guest
Username: Password: Remember me
Visual Objects

Please use this forum to post questions about Visual Objects and Vulcan.NET
  • Page:
  • 1

TOPIC: Memory leaks in the program

Memory leaks in the program 1 year 8 months ago #1

  • ArneOrtlinghaus
  • ArneOrtlinghaus's Avatar Topic Author
  • Offline
  • Posts: 124
  • Karma: 1
When making self tests opening certain program items I saw that the programs always consume more memory - both, the VO-Win32 version and the X#-Dotnet version.
Using the Telerik Justtrace Memory profiler I could find the reasons.
The program allows to take a snapshot of all objects in memory, then a user can perform some actions like opening/closing a program item, and then a second snapshot can be taken.
The Memory profiler makes a comparison of all objects before and after and shows their object names in a list and the dependencies between them.

The culprit:
Objects were holding references on each other so that the Garbage Collector did not understand that all of them could be removed. Calling Destroy methods of one object in the destroy method of the other resolved this.

So in Dotnet are still valid the old VO garbage collector rules: the program should help to destroy objects where possible. What is impressive are the possibilities to analyze behavior of the programs from external.

Arne

Please Log in or Create an account to join the conversation.

Memory leaks in the program 1 year 8 months ago #2

Hi Arne,

Thanks for sharing! Agreed, when an app is ported to .Net, an endless pool of possibilities opens up..

But I must add that in general, the .Net garbage collector is much more sophisticated than that of VO and it should remove objects that have references to each other, if they both go out of scope, provided of course there are no other active external references to them! So this makes me suspect, maybe calling the Destroy() method had the effect of NULLyfing some other external reference to those objects?

See the code below, it shows that 2 objects with references to each other can be collected. Although obviously in your app the scenario is way more complicated, so something else could have prevented the GC from collecting them.

Chris

FUNCTION Start() AS VOID
DoTest1()
DoTest2()
RETURN

FUNCTION DoTest1() AS VOID
LOCAL o1,o2 AS TestClass
o1 := TestClass{}
o2 := TestClass{}
o1:oRef := o2
o2:oRef := o1
RETURN
FUNCTION DoTest2() AS VOID
? "Press a key to invoke GC"
Console.ReadKey()
Gc.Collect()
? "GC invoked"
Console.ReadKey()
RETURN

CLASS TestClass
EXPORT oRef AS OBJECT
DESTRUCTOR()
? "Object collected"
END CLASS
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Memory leaks in the program 1 year 8 months ago #3

  • ArneOrtlinghaus
  • ArneOrtlinghaus's Avatar Topic Author
  • Offline
  • Posts: 124
  • Karma: 1
Hi Chris,
yes, it is true, that the GC in Dotnet is much better and resolves many of these relations. Surely it depends on the number of objects involved. In my case it was a chain of hundreds of objects connected together (Windows, servers, controls) - plus some additional drag+drop events programmed in C#. When removing the connections to these events all objects could be removed.

Please Log in or Create an account to join the conversation.

  • Page:
  • 1