Funarg problem: Difference between revisions

Revision as of 00:57, 25 January 2013

Revision as of 23:23, 23 February 2013

Line 6:

==Upwards funarg problem==

When one function calls another during a typical program's execution, the local state of the caller (including [[parameter (computer science)|parameter]]s and [[local variable]]s) must be preserved in order for execution to proceed after the callee returns. In most compiled programs, this local state is stored on the [[call stack]] in a data structure called an [[Call stack#Structure|activation record]] or ''stack frame''. This stack frame is pushed, or allocated, whenas aprelude functionto iscalling calledanother function, and is popped, or deallocated, when the other function returns to the function that did the call. The upwards funarg problem arises when the calling function refers to the called/exited function's state after that function has returned. Therefore, the activation record containing the called function's state variables must not be deallocated when the function returns, violating the [[stack-based memory allocation|stack-based function call paradigm]].

One solution to the upwards funarg problem is to simply allocate all activation records from the [[dynamic memory allocation#Heap-based memory allocation|heap]] instead of the stack, and rely on some form of [[Garbage collection (computer science)|garbage collection]] or [[reference counting]] to deallocate the activation records when they are no longer needed. Managing activation records on the heap is much less efficient than on the stack, so this strategy may significantly degrade performance. Moreover, because most functions in typical programs do not create upwards funargs, much of this overhead is unnecessary.