interactive: Don't leak temporaries into environment

Bug #553758 reported by Matt Giuca
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mars
Triaged
Wishlist
Matt Giuca

Bug Description

The code for interactive is pretty weird at the moment. Currently, for each statement, it:
- Compiles the statement into a sequence of instructions, some assigning temporaries,
- Executes each instruction, one at a time. Assignments to locals go in the "interactive local environment",
- If the statement is an expression, prints out the value of the final temporary.

This has a few problems:
- The temporaries assigned by intermediate instructions (or the final instruction, if an expression statement) remain in the environment after the execution of the statement (this can be seen with :e),
- The code confuses temporaries with "user variables" (the actual variables the user is requesting be assigned).

The new LLVM backend can't keep a persistent "local environment" around, since local variables are actual machine registers. These "user variables" are quite different from both globals and locals, since they can be assigned, but need to persist (and their types can change, for example).

Therefore:
- Add a new kind of variable, a "user" variable (this involves adding a new alternative to ir.varname),
- When generating code in the interactive environment, temporaries should still be local, explicit variables should be user variables,
- The interpret backend should store *three* environments -- global, user and local. user and local should not be threaded through function calls. The local environment should not be part of the executor -- it does not persist across interactive statements.
- Change executor.exec_instr to exec_instrs, which takes a list of instrs, and executes them atomically. Local variables (i.e., temporaries) persist across the instruction sequence, but are destroyed afterwards.

Tags: interactive
Revision history for this message
Matt Giuca (mgiuca) wrote :

Not important (wishlist, de-milestoning).

Changed in mars:
importance: Low → Wishlist
milestone: 0.3 → none
Revision history for this message
Matt Giuca (mgiuca) wrote :

Blocking LLVM backend, so milestoning.

Changed in mars:
importance: Wishlist → Medium
milestone: none → 0.3.1
Revision history for this message
Matt Giuca (mgiuca) wrote :

Don't worry about "user" variables. Just make a distinction between the actual named local variables (x, y, etc) and the temporaries ($T:0, $T:1, etc) when calling exec_instrs.

exec_instrs should take a list of instructions and also a set of varnames. The set of varnames denotes the variables which should be entered into the local environment upon executing the instr, which the back-end must be able to find on future calls to its methods. Any other variables bound by the instructions may be forgotten by the back-end.

This allows the LLVM backend to specially preserve the named variable names to be looked up again in future. Any unnamed variables are simply registers during the execution, and subsequently forgotten about.

Revision history for this message
Matt Giuca (mgiuca) wrote :

This is now highly-important, as the typedicts backend now executes a bunch of instructions when printing out values in interactive. Therefore, we generate lots and lots of temporaries very quickly (especially if using :e).

Changed in mars:
importance: Medium → High
Revision history for this message
Matt Giuca (mgiuca) wrote :

Note: As of trunk r1194 (fixing bug #710450), we can no longer see the temporaries using :e (it only displays the non-SSA variables which the user requested). But they are still present in the background (along with every value every variable has ever taken), so this should be dealt with at some point.

Revision history for this message
Matt Giuca (mgiuca) wrote :

As of trunk r1253 (bug #871725), this is much less severe. While we still leak temporaries into the environment, we reuse their numbers so we do not have a giant memory leak. Therefore, de-milestoning (again).

Changed in mars:
importance: High → Wishlist
milestone: 0.3.1 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.