Garbage collection consistency
BlitzMax Forums/BlitzMax Programming/Garbage collection consistency
| ||
| Hi, I have the following problem with memory management I have code like Type A ... Method Delete() End Method End TYpe Type B extends A ... Method Delete() End Method End Type TYpe C extends A ... Method Delete() End Method End Type IN a function when I do the following obj=New B obj = New B obj = New C obj = New C the Delete method is called for object of type B but not for object of type C why this inconsistency?. I canot share the code because it is proprietary. I am getting similar problem where the objects are not getting freed randomly. Regards |
| ||
| Can you provide a working example that will reproduce this "inconsistency?" It need not be code specific to your application, as long as you can show that this is occurring. Otherwise, I'm not sure I see a problem here. |
| ||
| There is no way to present the problem without reproducing the whole application. I did not get the memory problem for objects of other simplified types at the time it was tested. The following is the context of the code Type AnApplicationType Method AMethod() End Method End Type |
| ||
| There is no way to present the problem without reproducing the whole application. I did not get the memory problem for objects of other simplified types at the time it was tested. The following is the context of the code Type AnApplicationType Method AMethod() obj=New B obj = New B obj = New C obj = New C End Method End Type |
| ||
| There is no way to present the problem without reproducing the whole application. I did not get the memory problem for objects of other simplified types at the time it was tested so it is not possible to reproduce the problem. The following is the context of the code addendum to previous code Type AnApplicationType Field obj:A Method AMethod() obj=New B obj = New B obj = New C obj = New C End Method End Type Regards |
| ||
| If simple code doesn't reproduce it, it suggests the problem isn't where you think, and we have no chance of figuring it out with the info provided. |
| ||
| What are the places to do a hit test?. Isn't it illogical that the Delete method gets called for objects of type B and not for objects of type C irrespective of the context of the problem? Your help is appreciated Regards |
| ||
| Isn't it illogical that the Delete method gets called for objects of type B and not for objects of type C irrespective of the context of the problem? Yes, but that doesn't mean that's *your* problem. Add debuglog statements to your code an trace the function/method flow. |
| ||
| I would bet that your object C has a reference to a object D which itself has a reference to that object C or the like So even if you break all handles to both, they will never get cleared as they keep each other alive. |
| ||
| If Dreamora is correct, you should be able to null out the property references to each object C & D before your null their pointers. That may force GC to get rid of them. |
| ||
| I've never experienced the objects not being destroyed, but I can confirm that I've seen objects destroyed without delete methods being called. Fortunately, it doesn't seem to affect the TV3D module, but for my own game engine, I had to write my own resource management class to handle some objects and the rest are destroyed explicitly. When I trusted unmanaged resources to being freed in delete methods, they weren't always being called even though the objects were being collected. I'm not sure if there actually is a GC problem with not destroying objects or if it's just that the occasional failure to call delete methods when collecting objects destroys people's confidence. Sorry, I guess that just adds to the noise without improving the signal, doesn't it? |
| ||
| I have had objects not get destroyed until I cleaned out TLists inside of them. But, it may have been circular reference issue. |
| ||
| Many thanks for the advice, That seems to be the problem. I will get back with updated status soon. |
   |