After studying #896 I have a feeling that we handle certain source text & name storage badly. See AI agent text below (some might be slop), which summarises some of the flaws.
Current problems
-
REPL filenames exhaust bytecode name IDs. Every
<python-input-N>consumes an ordinary string ID; after roughly 65k inputs, newly encountered names can no longer fitu16operands. #896 fixes this. -
String literals share that limited ID space. Unique literals can still push subsequent names beyond
u16, even after #896. Tracked in #955. -
REPL source history grows indefinitely. Completed feeds retain their source even when nothing surviving needs it. Session dumps include that history. #896 removes retention for compilation failures, but not completed feeds.
-
eval()/exec()sources also accumulate. Each successful compilation retains source text, including repeated identical snippets. -
eval()/exec()compiled bodies accumulate too. Every invocation publishes a permanent function entry—eveneval("1"). These consumeu16function IDs, creating another cumulative exhaustion limit. -
Generated REPL filenames are stored redundantly. A feed number would suffice;
<python-input-N>could be formatted only for diagnostics.<string>is already static and does not have this problem. -
Identical source text is not deduplicated. Repeated feeds retain separate copies. Sharing
Arcs alone would not deduplicate their ordinary serde dump representation.
Underlying architectural issue
Code and source lifetime follows permanent session tables, rather than surviving owners. Reclaimable ownership—potentially using Monty’s heap—would let frames, functions and unresolved tracebacks retain what they need and release everything else.
That redesign must address:
- Active frames borrowing code and cached bytecode slices.
- Session-global function IDs embedded in bytecode.
- Transactional compilation/admission.
- Whole-program compilation before heap creation.
- Shared identity and compatibility in dumps.
Source deduplication and structured filenames reduce overhead; ownership-based reclamation addresses the underlying retention problem.
Activity
0No activity yet.