A data structure containing the important state information for a particular instance of a function call (or something that resembles a function call). May exist entirely in memory, or be partially stored in registers. Typically, an ActivationRecord contains the following:
A pointer to the ActivationRecord of the caller (commonly known as the DynamicChain?), though in a language with ContinuationPassingStyle even this isn't necessary (when the function returns, it does so via the supplied continuation; rather than the DynamicChain?).
In languages which allow nested LexicalScoping, a pointer to the ActivationRecord of the enclosing scope (aka the ReferencingEnvironment?) - this pointer is called the StaticChain. In most such languages, it is generally a requirement that somewhere up the call chain, the enclosing function have been called (but in concurrent languages it may have been called in a different thread). In languages like C/C++ where nested LexicalScopes are disallowed (or restricted), a StaticChain is unnecessary. Java InnerClasses also seem to be designed in order to avoid a StaticChain.
Local variables (frequently cached in registers)
Actual parameters to the function (also frequently cached in registers)
Space for the (eventual) return value of the function.
<add anything I forgot>
In many (most) programming languages, ActivationRecords maintain a strict LastInFirstOut discipline and are thus stored on a stack (often referred to as TheStack). For this reason, ActivationRecords are also commonly known as stack frames. In the context of languages (like C) where a stack is always used; this terminology is correct. As other languages don't use stacks for this purpose (many Smalltalk implementations, StacklessPython), ActivationRecord is a more correct term when talking about languages in general.
This scheme works well, unless you have the following features in your language (which violate LIFO discipline)