Home | History | Annotate | Download | only in interp

Lines Matching full:stack

18  * Stack frames, and uses thereof.
27 Stack layout
29 In what follows, the "top" of the stack is at a low position in memory,
30 and the "bottom" of the stack is in a high position (put more simply,
31 they grow downward). They may be merged with the native stack at a
38 value, which is passed through the interpreter rather than on the stack,
45 +-----------------+ <-- stack ptr (top of stack)
77 will be enough room for all possible "outs" on the stack before calling
80 All "V registers" are 32 bits, and all stack entries are 32-bit aligned.
86 We push two stack frames on when calling an interpreted or native method
90 stack might look like an uninterrupted series of interpreted method calls.
97 When calling a native method from interpreted code, the stack setup is
102 on the stack. The GC needs to scan them while the native code is running,
111 //#define PAD_SAVE_AREA /* help debug stack trampling */
116 * The idea is to mimic a typical native stack frame, with copies of the
118 * native code share the same stack, though this makes portability harder.
126 /* make it easier to trek through stack frames in GDB */
143 /* for interpreted methods: saved current PC, for exception stack
155 /* move between the stack save area and the frame pointer */
175 * Initialize the interp stack (call this after allocating storage and
181 * Push a native method frame directly onto the stack. Used to push the
182 * "fake" native frames at the top of each thread stack.
238 * Get the frame pointer for the caller's stack frame.
264 * Fill an array of method pointers representing the current stack
270 * Common handling for stack overflow.