| 1 | | |
| 2 | | |
| 3 | | = Layout of the stack = |
| 4 | | |
| 5 | | Every [wiki:Commentary/Rts/HeapObjects#ThreadStateObjects TSO object] contains a stack. The stack of a TSO grows downwards, with the topmost (most recently pushed) word pointed to by {{{tso->sp}}}, and the bottom of the stack given by {{{tso->stack + tso->stack_size}}}. |
| 6 | | |
| 7 | | The stack consists of a sequence of ''stack frames'' (also sometimes called ''activation records'') where each frame has the same layout as a heap object: |
| 8 | | |
| 9 | | || Header || Payload... || |
| 10 | | |
| 11 | | There are several kinds of [wiki:Commentary/Rts/Stack#KindsofStackFrame stack frame], but the most common types are those pushed when evaluating a {{{case}}} expression: |
| 12 | | {{{ |
| 13 | | case e0 of p1 -> e1; ...; pn -> en |
| 14 | | }}} |
| 15 | | The code for evaluating a {{{case}}} pushes a new stack frame representing the alternatives of the case, and continues by evaluating {{{e0}}}. When {{{e0}}} completes, it returns to the stack frame pushed earlier, which inspects the value and selects the appropriate branch of the case. The stack frame for a {{{case}}} includes the values of all the free variables in the case alternatives. |
| 16 | | |
| 17 | | == Info tables for stack frames == |
| 18 | | |
| 19 | | The info table for a stack frame has a couple of extra fields in addition to the [wiki:Commentary/Rts/HeapObjects#InfoTables basic info table layout]. A stack-frame info table is defined by {{{StgRetInfoTable}}} in [[GhcFile(includes/InfoTables.h)]]. |
| 20 | | |
| 21 | | [[Image(ret-itbl.png)]] |
| 22 | | |
| 23 | | The ''SRT'' field points to the SRT table for this stack frame (see [wiki:Commentary/Rts/CAFs] for details of SRTs). The return vector gives a vector of return addresses in the case of the {{{RET_VEC_SMALL}}} and {{{RET_VEC_BIG}}} types of return addresses; see [wiki:Commentary/Rts/HaskellExecution#VectoredReturns vectored returns] for more details. |
| 24 | | |
| 25 | | == Layout of the payload == |
| 26 | | |
| 27 | | Unlike heap objects which mainly have "pointers first" layout, in a stack frame the pointers and non-pointers are intermingled. This is so that we can support "stack stubbing" whereby a live variable stored on the stack can be later marked as dead simply by pushing a new stack frame that identifies that slot as containing a non-pointer, so the GC will not follow it. |
| 28 | | |
| 29 | | Stack frames therefore have [wiki:Commentary/Rts/HeapObjects#Bitmaplayout bitmap layout]. |
| 30 | | |
| 31 | | == Kinds of Stack Frame == |
| 32 | | |
| 33 | | {{{RET_BCO}}}, |
| 34 | | {{{RET_SMALL}}}, |
| 35 | | {{{RET_VEC_SMALL}}}, |
| 36 | | {{{RET_BIG}}}, |
| 37 | | {{{RET_VEC_BIG}}}, |
| 38 | | {{{RET_DYN}}}, |
| 39 | | {{{RET_FUN}}}, |
| 40 | | {{{UPDATE_FRAME}}}, |
| 41 | | {{{CATCH_FRAME}}}, |
| 42 | | {{{STOP_FRAME}}}, |
| 43 | | {{{ATOMICALLY_FRAME}}}, |
| 44 | | {{{CATCH_RETRY_FRAME}}}, |
| 45 | | {{{CATCH_STM_FRAME}}} |
| | 1 | [[redirect(wiki:Commentary/Rts/Storage/Stack)]] |
