- Joined
- Oct 27, 2007
- Messages
- 158
I have a hard time understanding why local handles leak anything memory wise. The reason being, when I look at local arguments and functions in assembly. For example:
Flat memory model, standard calling convention.
Main program execution.
mov eax, dword ptr [esi + 428af236h]
push eax
mov eax, edx
push eax
call SomeFunction
add esp, 8
push eax
call SomeOtherFunction
add esp, 4
Now comes the SomeFunction
push ebp
mov ebp, esp
cmp esp, someboundvalue
jle someaddress
push ecx
sub esp, 10h
mov eax, [ebp + 0ch]
lea eax, dword ptr [esi + 421e2cb8h]
// Function does its magic stuff here
// ..
add esp, 10h
pop ecx
pop ebp
return eax
The main program needs to call a function SomeFunction that needs an argument that points to an existing object in the heap. Note how the stack space is reserved for the handle/pointer.
The function SomeFunction creates a stack frame to access the arguments it needs and local variables workspace. The function does its stuff, releases the stack memory used locally, and returns a new handle/pointer to a newly created object.
Finally the returned reference is passed as an argument on the stack to a function called SomeOtherFunction. If this SomeOtherFunction doesn't keep a reference to the newly created object by SomeFunction (assuming it can't be asked for through another function), or doesn't request the removal of the newly created object after its done with it. Then that object is lost for use and hogs memory. A leak since there isn't a garbage collecter on the background that can deal with it. A leaking object, but not a leaking reference to it.
Therefore I don't see how a local handle/pointer can leak. The stack frame used which holds the handle/pointer variable is reused by some other function which on itself will create a stack frame on the same stack. This example passed a handle/pointer as argument and returned a new handle/pointer to a newly created object. The handle/pointer argument passed is released on the stack so it can't waste space the way I see it.
The new object stored in the heap can be commonly accessed through a handle/pointer that the function that creates the object provides. So there will always be one variable in the heap that holds the correct memory address of the object in the heap.
Functions needing a handle/pointer to an object got one when calling a function that creates an object and returns the handle/pointer to it. So the function does its stuff using the reference to that object and then releases the memory used for it. Atleast this is how I see it when thinking in terms of assembly code.
If somehow in the program a reference to an object is lost, the object can't be removed by the program itself that created the object. However a garbage collector should over time, when there're no active references to that object anymore. So I can understand objects leaking because there's no garbage collecting under the hood of Jass. The only reason I can come up with that somehow under the hood of Jass there's memory being allocated from the heap and not released properly. And I seriously don't see what I can do to prevent that while coding in Jass, concerning local variables. Objects I can destroy, locals, sure I can make them null pointers, but what's the point? How can something that is purely local (local handle pointers etc.) waste memory space?
Please don't answer it does, because of high increases of memory usage over a short time. I'd really like some more indepth information on this subject. Perhaps I'm just missing the obvious here, bear with me. Thanks for reading and thinking with me in advance
Flat memory model, standard calling convention.
Main program execution.
mov eax, dword ptr [esi + 428af236h]
push eax
mov eax, edx
push eax
call SomeFunction
add esp, 8
push eax
call SomeOtherFunction
add esp, 4
Now comes the SomeFunction
push ebp
mov ebp, esp
cmp esp, someboundvalue
jle someaddress
push ecx
sub esp, 10h
mov eax, [ebp + 0ch]
lea eax, dword ptr [esi + 421e2cb8h]
// Function does its magic stuff here
// ..
add esp, 10h
pop ecx
pop ebp
return eax
The main program needs to call a function SomeFunction that needs an argument that points to an existing object in the heap. Note how the stack space is reserved for the handle/pointer.
The function SomeFunction creates a stack frame to access the arguments it needs and local variables workspace. The function does its stuff, releases the stack memory used locally, and returns a new handle/pointer to a newly created object.
Finally the returned reference is passed as an argument on the stack to a function called SomeOtherFunction. If this SomeOtherFunction doesn't keep a reference to the newly created object by SomeFunction (assuming it can't be asked for through another function), or doesn't request the removal of the newly created object after its done with it. Then that object is lost for use and hogs memory. A leak since there isn't a garbage collecter on the background that can deal with it. A leaking object, but not a leaking reference to it.
Therefore I don't see how a local handle/pointer can leak. The stack frame used which holds the handle/pointer variable is reused by some other function which on itself will create a stack frame on the same stack. This example passed a handle/pointer as argument and returned a new handle/pointer to a newly created object. The handle/pointer argument passed is released on the stack so it can't waste space the way I see it.
The new object stored in the heap can be commonly accessed through a handle/pointer that the function that creates the object provides. So there will always be one variable in the heap that holds the correct memory address of the object in the heap.
Functions needing a handle/pointer to an object got one when calling a function that creates an object and returns the handle/pointer to it. So the function does its stuff using the reference to that object and then releases the memory used for it. Atleast this is how I see it when thinking in terms of assembly code.
If somehow in the program a reference to an object is lost, the object can't be removed by the program itself that created the object. However a garbage collector should over time, when there're no active references to that object anymore. So I can understand objects leaking because there's no garbage collecting under the hood of Jass. The only reason I can come up with that somehow under the hood of Jass there's memory being allocated from the heap and not released properly. And I seriously don't see what I can do to prevent that while coding in Jass, concerning local variables. Objects I can destroy, locals, sure I can make them null pointers, but what's the point? How can something that is purely local (local handle pointers etc.) waste memory space?
Please don't answer it does, because of high increases of memory usage over a short time. I'd really like some more indepth information on this subject. Perhaps I'm just missing the obvious here, bear with me. Thanks for reading and thinking with me in advance
