Nulling leaks..

12-17-2007, 02:17 PM

I'm not so sure about this, but I suppose I'm trying to figure things out on my own.

I'm guessing that non-nulled handles only link when associated with gamecache. Explanation: not nulling the handle increases the reference counter, and the I2S(H2I()) call in gamecache storage leaks a string for each new handle, since the ID constantly grows. In that case, if your map does not use gamecache at all, you wouldn't need to null local handles.

Is that correct?

12-17-2007, 03:20 PM	#2
WNxCryptic	Handles will leak, even without a gamecache. You need to nullify the local variables that you retrive handles into as well as flush the handles when you've finished with them. Other than that, just follow the normal rules for leaks and whatnot.

12-17-2007, 03:23 PM	#3
HINDYhat	I know that handles will leak unless you remove them. I'm just talking about the nulling part. Well what I said makes alot of sense. Not gamecache leakage, STRING leakage.

12-17-2007, 03:29 PM	#4
cohadar	You can have map that works normally no matter how big handle indexes are. For reference try the -torment test. (it can be found in ABC demo map)

12-17-2007, 06:33 PM	#5
Vexorian	Ghost reference take memory and slow down the allocator down, no matter what attachment system you use, don't go around leaking things you don't have to.

12-18-2007, 02:23 PM

cohadar

Quote:

Originally Posted by Vexorian

Ghost reference take memory and slow down the allocator down, no matter what attachment system you use, don't go around leaking things you don't have to.

Now I heard this claim multiple times. (and I believe it because I know blizz is lame) but is there any solid proof of this? any link to the test? maybe explanation how handle allocator works?

It is very strange considering that handle allocators can be made with O(1) complexity, I really see no reason why would blizzard do otherwise.

I know you are generally right: people should null handless just in case
but I am a person who likes to ask why.

So then, why isn't handle allocator O(1) ?

12-19-2007, 05:01 PM	#7
cohadar	bump? my question?

12-19-2007, 06:12 PM	#8
rain9441	The handle allocator probably is O(1) but the handle garbage collector probably isn't.

12-19-2007, 09:05 PM	#9
Toadcop	hmmm you can find a easy answer by trying this... pereiodical timer 0.001 period + call R2S(GetRandomReal(-34534534,5654655)) xD and wait hmmm some seconds... xD)))) i bet with handles is the same. (well almost) maybe a bit better =)

12-19-2007, 10:18 PM

#10

cohadar

Quote:

Originally Posted by rain9441

The handle allocator probably is O(1) but the handle garbage collector probably isn't.

Well if that is the case than increasing handle indexes absolutelly has no performance impact on game because recycler (aka collector) is simply a periodic thing that works constantly in his own thread.

@Toadcop whaaaaat?

12-19-2007, 10:53 PM

#11

Ammorth

IIRC strings are not handles.

Just did a test. It appears not nulling handles does cause some lag. Got up to 2mil leaks and my fps was halved.

JASS:

globals
    boolean TestOn = false
    integer leaks = 0
endglobals

function LeakLocation takes nothing returns nothing
    local location l = Location(0.,0.)
    call RemoveLocation(l)
endfunction

function LeakGroup takes nothing returns nothing
    local group g = CreateGroup()
    call DestroyGroup(g)
endfunction

function CallBack_test takes nothing returns nothing
    if TestOn then
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        call LeakLocation()
        call LeakGroup()
        set leaks = leaks + 50
    endif
endfunction

function H2I takes handle h returns integer
    return h
    return 0
endfunction

function Trig_Melee_Initialization_Actions takes nothing returns nothing
    local location l
    if TestOn then
        set TestOn = false
        set l = Location(0.,0.)
        call BJDebugMsg("|cFFFFCC00Test Paused")
        call BJDebugMsg("Current Handle References Lost: "+I2S(leaks))
        call BJDebugMsg("Current Handle ID: "+I2S(H2I(l)))
        call RemoveLocation(l)
        set l = null
    else
        set TestOn = true
        call BJDebugMsg("|cFFFFCC00Test Started")
    endif
endfunction

//===========================================================================
function InitTrig_Melee_Initialization takes nothing returns nothing
    set gg_trg_Melee_Initialization = CreateTrigger(  )
    call TriggerRegisterPlayerEventEndCinematic( gg_trg_Melee_Initialization, Player(0) )
    call TriggerAddAction( gg_trg_Melee_Initialization, function Trig_Melee_Initialization_Actions )
    call TimerStart(CreateTimer(), 0.01, true, function CallBack_test)
endfunction

12-20-2007, 08:17 AM

#12

cohadar

2,000,000 ?

And it is still not an answer to why.

EDIT:
Well after playing with your test a little I just realized that handle allocator is actually not O(1)

How do I know?
Well fps drops only while test is working (a.k.a while new handles are requested for things to leak)
when you pause test fps jumps back to normal.

Well I guess blizz won lamer of the year award again....

PS: my estimate is that it is O(log n) in case anyone cares

12-20-2007, 11:26 AM	#13
HINDYhat	Wow, that would be the lamest thing EVER... We need someone like PipeDream or Vexorian to prove this first though. If anything you should make a null-leak -> FPS graph and find the algorithm behind it (dunno if that would really work, but meh).

12-20-2007, 12:21 PM	#14
Strilanc	A few facts about handle-leaks: - You can only handle-leak a given handle once, no matter how many times you screw up its reference count - You haven't "really" handle leaked unless you destroy the handle (in that case the normal leak includes it) The behavior is a lot like handles are tombstones, and the editor manages dead tombstones for you (except for the ref bug).