gh-119786: Edit InternalDocs/frames.md, Python/vm-state.md, Python/tier2_engine.md
#124450
Conversation
InternalDocs/vm-state.md
Outdated
|
|
||
| There are some other fields in the frame structure of less importance; notably frames are linked together in a singly-linked list via the `previous` pointer, pointing from callee to caller. | ||
| The frame also holds a pointer to the current function, globals, builtins, and the locals converted to dict (used to support the `locals()` built-in). | ||
| A pointer to the current frame is held in `frame`, for more information about what `frame` contains see [Frames](frames.md): | ||
|
|
There was a problem hiding this comment.
CC @markshannon
I can't comment on lines that haven't changed, so this is for a number of comments on vm-state.md.
L 21: The interpreters share an implementation of what? The frame? Caches the depth - is this stack depth?
L 40: Add a link to exception_handling.md.
L45: Not sure what you mean here: "The implementation of jumps within a single Tier 2 superblock/trace is just that, an implementation."
L51: "within the superblock" is repeated twice.
L52: what cannot be modified?
I think it might be worth moving the contents of the "Thread state and interpreter state" section to the beginning, as a high level overview of the components of the state, and then drill into the parts.
The "Tier 2 IR format" section doesn't seem to belong to the vm-state topic at all.
There was a problem hiding this comment.
The interpreters share an implementation of what?
Both tier 1 and tier 2 use the same canonical in-memory representation. Tier 2 might store some values temporarily in registers, but that should be invisible to other code. The reason this is noteworthy is that other VMs, e.g. HotSpot can have different frame layouts for the compiler and interpreter.
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
There was a problem hiding this comment.
It isn't clear what "vm state" is meant to cover here.
I think the sections on frames and unwinding should be moved to their own files.
The core "vm state", ie. the state needed to execute code is just the thread-state pointer.
From the thread-state, the frame pointer, and thence the stack and instruction pointers can be read.
When executing code however, the stack pointer, frame pointer and instruction pointers are cached in the interpreter (or jitted code).
The frame and instruction pointers are kept up to date in memory, the local versions are just cached for speed. The stack pointer is a bit different in that the in-memory version is marked as invalid, as keeping the local and in-memory versions in sync would be too expensive.
InternalDocs/vm-state.md
Outdated
|
|
||
| There are some other fields in the frame structure of less importance; notably frames are linked together in a singly-linked list via the `previous` pointer, pointing from callee to caller. | ||
| The frame also holds a pointer to the current function, globals, builtins, and the locals converted to dict (used to support the `locals()` built-in). | ||
| A pointer to the current frame is held in `frame`, for more information about what `frame` contains see [Frames](frames.md): | ||
|
|
There was a problem hiding this comment.
The interpreters share an implementation of what?
Both tier 1 and tier 2 use the same canonical in-memory representation. Tier 2 might store some values temporarily in registers, but that should be invisible to other code. The reason this is noteworthy is that other VMs, e.g. HotSpot can have different frame layouts for the compiler and interpreter.
|
Would it make sense to separate the move from any editing we want to do? Maybe do the move first in one PR, so everything is in the same folder, then do the edits in other PR(s)? |
If it helps to split, then I would rather edit then move, so that we know that what's in the new folder is good. |
Eclips4
changed the title
Python/vm-state.md and Python/tier2_engine.md to the InternalDocsInternalDocs/frames.md, Python/vm-state.md, Python/tier2_engine.md`
Eclips4
changed the title
InternalDocs/frames.md, Python/vm-state.md, Python/tier2_engine.md`InternalDocs/frames.md, Python/vm-state.md, Python/tier2_engine.md
I just changed a few lines in the
vm-statefile to not describe the frames, but instead refer to theframesthemselves. I also added a link to thetier2_enginein the short description for tier 2.