One solution to the upwards funarg problem is to simply allocate all activation records from the heap instead of the stack and rely on some form of garbage collection or reference counting to deallocate them when they are no longer needed.
This will cause a different behavior in the case of mutable variables, because the state will no longer be shared between closures.
The problem in this case exists if the compose function allocates the parameter variables f and g on the stack.
Nonetheless, the existence of downwards funargs implies a tree structure of closures and stack frames that can complicate human and machine reasoning about the program state.
The downwards funarg problem complicates the efficient compilation of tail calls and code written in continuation-passing style.
In these special cases, the intent of the programmer is (usually) that the function run in limited stack space, so the "faster" behavior may actually be undesirable.
[citation needed] The Java programming language deals with it by requiring that context used by nested functions in anonymous inner and local classes be declared final, and context used by lambda expressions be effectively final.
This is usually accomplished by representing function values as heap-allocated closures, as previously described.
The OCaml compiler employs a hybrid technique (based on static program analysis) to maximize efficiency.