activation record

activation record

[‚ak·tə′vā·shən ′rek·ərd]
(computer science)
A variable part of a program module, such as data and control information, that may vary with different instances of execution.

activation record

(compiler)
(Or "data frame", "stack frame") A data structure containing the variables belonging to one particular scope (e.g. a procedure body), as well as links to other activation records.

Activation records are usually created (on the stack) on entry to a block and destroyed on exit. If a procedure or function may be returned as a result, stored in a variable and used in an outer scope then its activation record must be stored in a heap so that its variables still exist when it is used. Variables in the current scope are accessed via the frame pointer which points to the current activation record. Variables in an outer scope are accessed by following chains of links between activation records. There are two kinds of link - the static link and the dynamic link.
References in periodicals archive ?
Commands can be sent to read or write specific data fields from the customer activation record stored in the Safe Activation server during the product activation process.
In a stack-based scheme, an activation record will be pushed onto the stack when function f is invoked; then each time before g is called, certain variables in registers must be saved to the stack.
The idea is that we can allocate most parts of the current activation record in callee-save registers.
Because activation records are also allocated in the heap, they can be shared with other heap-allocated closures.
In a companion paper [Appel and Shao 1996], we show that stacks do not have a significantly better locality of reference than heap-allocated activation records, even in a modern cache memory hierarchy.
Appel [1992] also noticed that programs using linked closures,(1) or stack-allocated activation records, may cause a compiled program to use much more memory.
To support the SSC scoping rule for cases like the compile function, we treat all activation records as closure environments for continuation functions.
Each of these may require nontrivial changes to the basic scheme such as sharing activation records, inserting special markers in the middle of a frame, and randomly updating the return address.
Instead, we treat all activation records as closures for continuation functions and allocate them in registers or in the heap.
We first use examples to review the continuation-passing and closure, passing intermediate languages and to show how activation records might be allocated in the heap and in callee-save registers (Section 3).
We use CPS as the intermediate language for closure conversion because we want to treat all activation records as continuation closures.
As we argued at the beginning of Section 3, we use CPS as the intermediate language because we want to treat activation records as continuation closures.

Full browser ?