A Question on the Nature of Memory Leaks

[theoligarch]

I'm fairly new to the WE, and I've stumbled across different tutorials on leaks and how to avoid them. So far I'm not too worried since I'm only making an altered melee map with a pretty minimal amount of triggering. But something still confuses me. Everyone talks about these leaks in terms of "location"; the game loses track of where a unit is. The solution, they say, is to remove the location immediately after using it. Does it work instead just to remove the unit? So, for example, I have a trigger that creates a dummy unit at a target location, but then removes the dummy unit a few second later. I also have a few triggers that create units at specific spots without removing them, but they're not looping. Some clarification here would be great, especially if I'm just misunderstanding leaks altogether (the tutorials I looked at didn't have very clear explanations for someone just starting).

 

[IcemanBo]

Hello, you can have a look in my signature to read about memory leaks.
Take your time to read the chapters you are interested in and then feel free to ask things that are still unclear.

 

[theoligarch]

A dynamic object gets created at runtime.
You lose access to it when it falls out of scope.

I don't know what this means. What scope?

Once you create an object you also have to destroy it properly after usage. If you don't destroy the object, but also can't refer to it it anymore, this is what is called memory leak

What do you mean by usage? How does the game lost its reference to the object? Why do you use "object" where other tutorials talks about "location"?

 

[Dr Super Good]

What do you mean by usage?

All objects you create have a life cycle. Some might be the entire sessions (eg a spawn location which never is destroyed). Others might be just a few function calls such as a temporary location. What is important is that all objects get destroyed after their useful life cycle ends otherwise they will persist in memory until the end of session eating up resources.

How does the game lost its reference to the object?

The game does not, just the triggers do. At that stage it becomes impossible to order an object to be removed and hence the leak becomes permanent until the end of session.

To understand this you need to think of handle objects in JASS terms. Each object is assigned a unique "handle id" which is used by the appropriate type of variable to reference the object. If you lose track of this handle id before destroying the object you cannot later destroy it since you cannot ever get its handle id back. At that stage the leak is permanent until the end of session.

Why do you use "object" where other tutorials talks about "location"?

Locations are a type of handle object. Handles are used as a safe referencing system to objects so that objects that are destroyed can be evaluated to null rather than exposing trigger scripts to potentially invalid object data and memory locations when evaluated. Handle ids are themselves a sort of resource and can leak. They are automatically recycled once their reference counter reaches 0, unlike the objects they are given to reference, making them less prone to leaking so generally you do not need to worry about them. That said some GUI actions leak handle ID as a result of local declared local variables being able to leak reference counts on function return.

If leaks are a big problem for you I recommend trying to mod StarCraft II since such objects are automatically garbage collected in it.

 

[IcemanBo]

Dynamic
by that, that you create it via trigger. For example you create something in "Centre of Rect".
This creates a location internaly that you can use it.
It works just fine and you can do that. But after done so the created location still exists, but will stay unused.
But you don't have access to this location anymore -> leak.

Usage,
for example "Create Unit at (Centre Of Rect)". Here you use "(Centre of Rect) object.
"Location" is just a specification. Simple as that.

So after usage you need to remove it. (with help of variable like explained in tutorial)

 

[Wietlol]

It is simple.
You have a massive bag and in that bag there are a huge amount of stuff in it.
You carry that bag with you because there are things in it that you want to use now and then.
When you don't need certain stuff in the bag any more, it is not really meaningfull to carry it with you.
If you don't get rid of the unused stuff or use too much stuff at all, your bag will eventually become so heavy that it will slow you down or maybe even just make you collapse.
So it is better to remove the stuff that you don't need. (Best thing to do this from the moment that you don't need it any more.)

In your Wc3 bag, you have units, locations, groups, players, regions, timers, texttags, etc, etc, etc.
You add something to your bag when you create it and throw it away when you call some nice remove functions on it.
If you don't remove the stuff, your Wc3 will slow down and eventually just crash.

 

[theoligarch]

Okay, thanks guys, that's really helpful. So when I specify where a unit should spawn, the spot/location where I spawned it is itself an object that the game has to hold onto, despite it's uselessness (unless I take the time to manually remove the spot/location). So even if I remove the unit that was spawned, there's still something left over from its creation: the location where I created it. Is that correct?

 

[IcemanBo]

Yes, that is correct, the location where the unit was created does still exist.

 

[theoligarch]

Perfect. Now I see why I need to clean them up. Memory leaks made total sense for talking about more concrete things, like dummy units, but now I see it applies to more abstract parts of the game that must be kept track of. Thanks! That's all I needed.