Galaxy Editor = No leaks right?

[Vicboy]

Right??? They must have thought about that...

 

[phyrex1an]

Presumably there is a garbage collector embedded in the runtime. I think Natives.galaxy has some description of what types are garbage collected.

However, it's time to kill of the myth that Garbage Collector == No Leaks. That isn't true. A Garbage Collector determines what is garbage by checking what values are no longer reachable from the global environment. Depending on the algorithm there might be false negatives (stuff that isn't reachable but still isn't considered garbage), though if Blizzard was reasonable intelligent they didn't implement such an algorithm. However, if you for some reason forgets to remove a global reference to an object it will never be removed even if you'll never reference it again. Thus, we have a leak that no garbage collector in the world will be able to remove (unless we want to introduce false positives, an extreme evil).

For example, say that we have a garbage collected type A. Now we want to track all A's created by our code so we use a collection (an array in this case) to store each A created. Now when we no longer wants to use our A we must remove it from that collection (akin to how you had to RemoveLocation when we no longer wanted it) or else garbage collection will never take place.

tl;dr: A garbage collector only removes the obvious garbage, the non obvious ones you still have to fix yourself or else you'll leak memory.

 

[Jesus4Lyf]

//--------------------------------------------------------------------------------------------------
// About Types
//--------------------------------------------------------------------------------------------------
//
// -- Complex types and automatic deletion --
// 
// Many native types represent "complex" objects (i.e. larger than 4 bytes).  The script language
// automatically keeps track of these objects and deletes them from memory when they are no longer
// used (that is, when nothing in the script references them any longer).  The types which benefit
// from automatic deletion are:
//
//      abilcmd, bank, camerainfo, marker, order, playergroup, point,
//      region, soundlink, string, text, timer, transmissionsource, unitfilter, unitgroup, unitref,
//      waveinfo, wavetarget
//
// Other object types must be explicitly destroyed with the appropriate native function when you
// are done using them.

Source.

 

[celerisk]

... say that we have a garbage collected type A. Now we want to track all A's created by our code so we use a collection (an array in this case) to store each A created. Now when we no longer wants to use our A we must remove it from that collection (akin to how you had to RemoveLocation when we no longer wanted it) or else garbage collection will never take place.

I would very much complain if it removed something I've still stored somewhere.
That's not a leak either in my book.

 

[No_exit]

@ phyrex1an:
You will not leak memory since your global variables / arrays have a pre-defined size. You will however have to clean it up somehow because otherwise you will end up with code starting to act weird or even crash when that array is completely full.

 

[phyrex1an]

@ phyrex1an:
You will not leak memory since your global variables / arrays have a pre-defined size. You will however have to clean it up somehow because otherwise you will end up with code starting to act weird or even crash when that array is completely full.

I guess memory leaks never existed then since your computer has a pre-defined memory pool... Though, fair point. If you can't allocate new memory then memory leaks doesn't exists. But you can allocate new memory in sc2. The question is, can any of these data structures you create reference another data structure? In that case, garbage collection doesn't solve all your leaking problems. Besides, manual allocators (such as unit indexer) are also subjects to memory leaks as you say "You will however have to clean it up somehow".

I would very much complain if it removed something I've still stored somewhere.

Me too. Citing myself: "unless we want to introduce false positives, an extreme evil". Though it would be neat if a garbage collector could solve the halting problem and remove all memory that I will never use again automagically...

That's not a leak either in my book.

Well, perhaps I'm liberal in my definition but memory that hangs around that I no longer wants to use is a memory leak in my book. Some language designers agree with me though and introduces stuff like weak references and other kludges.
Edit: I hate to fall back on a appeal to authority but if we can't even agree on what a leak really is then there isn't much to be said about the subject...

 

[celerisk]

if we can't even agree on what a leak really is then there isn't much to be said about the subject...

Weak attempt at a definition:
A leak happens when you lost the (last) reference to an object but the object is still around.

At least, that's what I'm working with.

 

[phyrex1an]

And my definition is: A leak happens when you'll never reference an object but the object is still around.

A reformulation could be this (I hope this will convince you that my definition is more useful ): A memory leak happens when a piece of memory can be reclaimed without altering program behaviour (modulo time and space usage ofc) but isn't reclaimed.

Depending on context you might want to add an "eventually reclaimed" clause somewhere.

 

[No_exit]

@ phyrex1an:
Your definition is very strong but it has the disadvantage that the effect of a memory leak can anywhere between "not noticeable" and "crash". I'm pretty sure that the original post only cares about things that make his pc significantly slower or make it crash.

Also note that in practice "you'll never reference an object" is very hard, if not impossible to determine (equivalent to halting problem probably).

So to answer if there are any memory leaks that can cause your pc significantly or make it crash, do we all agree on the parts below?
- Global variable non-arrays are fine to use.
- Global variable Arrays are fine to use but you yourself are in charge to make sure that previously unused indexes of the array that are no longer used are recycled such that the array will not overfill.
- Local variables are fine to use as long as the function is not put in an infinite loop (with waits between them).
- If there are any variables which are circular (as in variables referring each other; for galaxy I think the only ones are structs) then you should dereference the links to each other until it is no longer circular and then the garbage collection can clean it up.

The only thing I think is possible for a memory leak is to have some sort of local function which allocates memory but is then put in an infinite long wait. This function needs to be called a lot then. But yeah, you deserved to have your memory eaten then.

 

[Zwiebelchen]

To sum it up for those that do not understand very much of programming:

You do not need to null your locals at the end of your functions anymore (memory leaks are gone), however, you should still destroy/remove the handle they were pointing to, in case it was a handle variable. The garbage collector solves some of those cases too, but is not able to solve all cases. You should not trust in the garbage collector, but program clean in the first place. For readability, its better anyways (and well ... it 'looks' better ... I've always been a perfectionist ).

So, to express it with JASS terms: You need to DestroyGroup(), but you do not need to set group = null after that.

 

[Jesus4Lyf]

So, to express it with JASS terms: You need to DestroyGroup(), but you do not need to set group = null after that.

What? Did no one read my post? There is no destroy group, it actually destroys the objects when you no longer need them, like Java or something else...

 

[phyrex1an]

it actually destroys the objects when you no longer need them

Um no, that's the point. It actually destroys the objects when you no longer references them [from the global scope]. Memory leaks are still possible, just like in Java or something else.

Edit: Though, a destroy group equivalent isn't the solution... The solution is to make sure that you no longer reference stuff that you want garbage collected.

 

[Zwiebelchen]

Um no, that's the point. It actually destroys the objects when you no longer references them [from the global scope]. Memory leaks are still possible, just like in Java or something else.

Edit: Though, a destroy group equivalent isn't the solution... The solution is to make sure that you no longer reference stuff that you want garbage collected.

So basicly its the exact opposite of what I said: Always null every handle variable properly, to make sure you kill the reference to the object. I didnt know that Galaxy doesnt have destroy funcs anymore. ... Weird. As if blizzard wants to force us to generate unclean code.