[JASS] confused about hashtables

[maskedpoptart]

"All handle objects saved or removed from a hashtable are automatically reference-counted (with the exception of TextTag, Lightning, Image, Ubersplat, and FogState). This allows handle objects to be saved in the hashtable without risk of the object’s being prematurely memory freed. The reference counts are updated when an object is either added to, flushed, or overwritten in a hashtable." -Karune

Can someone please explain in detail what this means? From what I understand, if the hashtable is flushed, any handle that no longer has references will be destroyed using the appropriate function. For example,

local hashtable ht = InitHashtable()
local location loc = Location(23.0, 47.0)
call SaveLocationHandle(ht, 0, 0, loc)
call RemoveSavedHandle(ht, 0, 0)

this would not destroy the loc variable, but

local hashtable ht = InitHashtable()
local location loc = Location(23.0, 47.0)
call SaveLocationHandle(ht, 0, 0, loc)
set loc = null
call RemoveSavedHandle(ht, 0, 0)

this would destroy it automatically?

Also, I'm assuming you can make hashtables of struct instances since they are basically integers. However, this would mean a ton of potential leaks when flushing the hashtables. They do not reference count integers and do not know to call destroy(), right?

 

[Element of Water]

Well I'm just generally confused about hashtables, as they don't seem to exist in my warcraft (it is patched to 1.23).

 

[maskedpoptart]

http://www.hiveworkshop.com/forums/...s-101/patch-1-23b-jass-gui-and-gaming-131095/
see this thread. The patch (1.23b) is only in beta right now, but you can download it in Westfall. Basically, hashtable is a better version of gamecache.

 

[Element of Water]

ah, k, I'm in Northrend. I'll check it out.

 

[Storyyeller]

Ok: Here's what reference counting means

A pointer is simply a number that tells you the location in the memory where a specific piece of data is stored. In JASS, Handles are basically pointers.
Why use handle? Suppose you had a function that took a unit for the argument, say LevelUpHero. You wouldn't want to copy the unit every time you called the function!
Instead, a handle is passed. The handle is a number that tells you which unit the function should be applied to.
In JASS, every datatype except for integers and reals is really a handle.

Now here's the problem. Suppose you have a Timer (let's call it T) that you aren't using anymore. How do you get rid of it? You could try
set T = null

However, T is not the timer itself, just the handle that refers to the location of the timer. The actual timer still exists and takes up memory, even though we don't want it to. This is how memory gets 'leaked'.
So we do this instead
call DestoryTimer(T)
When we do this, Warcraft searches for the timer that T refers to and destroys it.


Now how does reference counting fit into this?
In the example above, we could destroy the timer because we were sure we wouldn't need it again. However, what if we forget? Or even worse, what if we accidentally destroy the timer before we are really done with it?Wouldn't it be nice if the computer could figure out for us and automatically destroy the timer when it isn't needed?

In order to use a timer, you need the handle that refers to it. If there aren't any handles that refer to the timer anymore, it can't be used, so the computer knows that it is safe to destroy.
The way it determines whether there are any handles is by reference counting. Each time a new handle is changed to refer to the timer, the reference count is increased by 1. Each time a handle that used to refer to the timer is changed to refer to something else, the count is decreased by 1. When the count reaches 0, that means there are no more handles left and the timer is safe to destroy.

 

[maskedpoptart]

Thank you for the clarification. I knew most of what you explained, but it was still helpful. I was mainly confused about how reference counting worked in JASS (since the only time it is being done is in hashtables).

 

[aznricepuff]

Handles never get automatically garbage collected in wc3 anyway, which is why you have to call RemoveLocation() and DestroyEffect() and all that good stuff.

Reference leaks are from this bugged handle reference system wc3 has whereby handle variables aren't even references to handles; they store indexes to arrays of handle references. When a handle's reference count reaches 0, it's not the handle that gets garbage collected, it's the handle's index (what H2I() used to return and what GetHandleId() now returns) that gets recycled.

Unfortunately, blizz never decided to make wc3 decrease reference count when a handle variable goes out of scope, so we have to null those variables ourselves. Forgetting to null handle variables won't leak the actual handle object (forgetting to destroy it does), it'll just leak that handle reference index, which is a very minor thing, but one better avoided nonetheless.

 

[maskedpoptart]

So in hashtables, wc3 is removing reference leaks, not garbage collecting, when the reference count reaches 0? Does that mean we have to destroy our own handles before calling RemoveSavedHandle or FlushChildHashtable or FlushParentHashtable?

 

[aznricepuff]

You can't remove a handle from a hashtable after you've destroyed it because it won't exist anymore. I'm not sure if hashtables automatically flush handles once theyve been destroyed, though.

 

[maskedpoptart]

Okay. My main question now is:
If you remove a handle from a hashtable, causing the handle's reference count to reach 0, does wc3 destroy the handle?

 

[aznricepuff]

no. wc3 never automatically destroys handles.

EDIT: Ok, there ARE exceptions to this, like texttags if you set permanence to false and a finite lifespan. But basically anything you needed to destroy manually when not using hashtables you STILL need to destroy manually when using hashtables.