CSE Machine: Visual garbage collector

[alsonleej]

Description

Currently, frames that will no longer be referenced still show up as white in the environment, along with their associated bound objects. There was previously no mechanism to visually "garbage collect" frames which should have been dereferenced. This PR fixes this, by having the default color be faded, and for each step in the CSE Machine, we mark the current environment as reachable, and then recursively mark its parent frames (with their bindings) as reachable, up till the root parent (Global).

Type of change

• New feature (non-breaking change which adds functionality)

How to test

// frames being abandoned
// let x = 0;
// let y = 10;
// while (x < 1) {
//     x = x + 1;
//     {
//         let y = 20;
//         continue;
//     }
// }
// pair(x, y);
// 3;

// frames being abandoned 2
// let x = 3;
// let i = 4;
// for (let i = 0; i < 30;  i = i + 1) {
//     x = x + i;
// }
// const k = [1,2,3];

// function closures dereferncing
// function a(b,c) {
//     function f(c) {
//         return 3*c;
//     }
//     return f(b)+c;
// }
// function j(b,c) {
//     function f(c) {
//         return 3*c;
//     }
//     return f(b)+c;
// }
// a(5,2);
// j(6,2);

//test array referencing
// const f = x => 1;
// {
// const a =[1,2,f];
// }
// f(3);

Demo

Frames and bindings (such as function closures) will indicate as grey, once they will be no longer accessed.

garbagecollector.mp4

Nested referencing within ArrayUnits are also updated.

gc_array.mp4

Checklist

• I have tested this code
• I have updated the documentation

[coveralls]

Pull Request Test Coverage Report for Build 14256302577

Details

• 31 of 45 (68.89%) changed or added relevant lines in 19 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.09%) to 31.198%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/features/cseMachine/animationComponents/FunctionApplicationAnimation.tsx	0	1	0.0%
src/features/cseMachine/animationComponents/InstructionApplicationAnimation.tsx	0	1	0.0%
src/features/cseMachine/java/components/Control.tsx	0	1	0.0%
src/features/cseMachine/java/components/Stash.tsx	0	1	0.0%
src/features/cseMachine/components/values/ContValue.tsx	0	2	0.0%
src/features/cseMachine/java/components/Environment.tsx	0	3	0.0%
src/features/cseMachine/components/Frame.tsx	4	9	44.44%

Files with Coverage Reduction	New Missed Lines	%
src/features/cseMachine/components/values/ContValue.tsx	1	0.0%

Totals
Change from base Build 14256181806:	0.09%
Covered Lines:	4911
Relevant Lines:	14857

---

💛 - Coveralls

[arnav-goel10]

I noticed some cases where the reachability logic doesn’t fully reflect actual references:

1. Indirect referencing through nested arrays

function test_func() {
    const x = [];
    const y = [x];
    const a = [x, y];
    return a;
}

const result = test_func();
result[1][0] = 5;

In this case, x, y and a are still indirectly accessible via the returned result array, result[0] gives x, and result[1][0] also accesses x. However, the visualization currently marks them as unreachable (faded out), even though they are still referenced.

Source.Academy.-.Personal.-.Microsoft.Edge.2025-04-02.18-21-18.mp4

---

2. Function still referenced after return

function test_func() {
    const x = [];
    const a = d => d + 1;
    return a;
}

const result = test_func();
result(5);

In this example, test_func() returns a function a, which is saved in the variable result. Even though test_func finishes running, the function a still exists and can be used as it hasn’t been lost or deleted. This means the frame where a was created is still needed and should not be marked as unreachable.

Right now, the visualization marks the frame as unreachable as soon as test_func() returns, even though a is still being held in result. This gives the wrong impression, it looks like the frame has been garbage collected, even though the function is still accessible and working.

Also, when result(5) is called, the visualization updates and marks the frame as reachable again. But this shouldn't happen. Once a frame is marked as unreachable (like garbage collected), it shouldn't become reachable again.

Source.Academy.-.Personal.-.Microsoft.Edge.2025-04-02.18-36-28.mp4

[alsonleej]

unfortunately, after 12 consecutive hours, i still can't figure out why even when isReachable is true, the object does not change its color. debugging is pain.

possible ideas for future:

1. each object to inherit a setReachable() method, and calls each other in a chain. Frame to call setReachable in bindings (key and values) and arrows (to parent frames). ArrayValue calls setReachable for each of its ArrayUnits (key and value (which may be references)). FnValue to setReachable on its ArrrawFromFn and enclosing frame (only if enclosing frame is not already reachable, to avoid an infinite loop).

Unfortunately changing the color of the enclosing frame for some reason doesn't work no matter what I do, yet everything else updates its color by setting isReachable. (also a word of warning: i cannot set the target of an arrow to be reachable, as the target remains undefined until countingSteps or later. console.log() did not help me, turns out it givesobject references instead of object state. i wasted way too long to find out. thanks google.)

2. perhaps there could be some pre-processing, where before any drawing, we already do 3x DFS (from current environment, from control env instruction, and from pair/array and closure from stash) to mark all reachable objects. Then when the actual drawing starts, it is colored based on this. I'm not sure where to do this though.

[alsonleej]

2. Function still referenced after return

function test_func() {
    const x = [];
    const a = d => d + 1;
    return a;
}

const result = test_func();
result(5);

In this example, test_func() returns a function a, which is saved in the variable result. Even though test_func finishes running, the function a still exists and can be used as it hasn’t been lost or deleted. This means the frame where a was created is still needed and should not be marked as unreachable.

Right now, the visualization marks the frame as unreachable as soon as test_func() returns, even though a is still being held in result. This gives the wrong impression, it looks like the frame has been garbage collected, even though the function is still accessible and working.

Also, when result(5) is called, the visualization updates and marks the frame as reachable again. But this shouldn't happen. Once a frame is marked as unreachable (like garbage collected), it shouldn't become reachable again.

Source.Academy.-.Personal.-.Microsoft.Edge.2025-04-02.18-36-28.mp4

After way too long debugging this, I found that the enclosing environment of the bottom FnValue does not actually refer to the existing frame, but re-creates it. So when I was setting setReachable on the FnValue's enclosing frame, it actually sets a different object.

More details here #3127