Infinite loop (in scheduler?)

[mindplay-dk]

(You said in #84 you thought this problem was fixed, but I still have this issue with version 1.8.7 - I'm opening a separate issue to avoid getting sidetracked in other issues.)

I've created a preliminary benchmark, which sometimes causes Chrome to lock up:

The only way out is to kill the browser tab via Chrome's task manager.

To recreate the problem, be sure to build the fre benchmark with npm run build-prod - for some reason, the problem doesn't seem to appear with npm run build-dev, not sure (?)

Click on the button to create 10,000 rows - then click repeatedly on the "update" and "swap" buttons, which seem most likely to trigger the problem.

[yisar]

I debugged the benchmark, there are two reasons:

1. Scheduling problem. Our scheduling is to execute as many tasks as possible in the idle time, so when there are 10000 tasks, they will loop too many times.

2. Diff algorithm. Because swap is the replacement of 9999 and 2, according to our current diff algorithm, 9998 inserts will be performed, which will cause browser crash.

[mindplay-dk]

I looked around, and there's not much to go on - but I did find this:

vuejs/vue@850555d#diff-9ddd49414faddc237ff7c47aedcb12ff

It looks like Vue also had problems with MessageChannel and switched to MutationObserver instead?

The commit log says this fixed a number of problems:

Here's the current version on their dev-branch:

https://github.com/vuejs/vue/blob/dev/src/core/util/next-tick.js

Maybe this is helpful? That's all I could find.

[yisar]

I'm back. I fixed this bug now.

The behavior of fre is now similar to react. When the task has expired, it will render synchronously.

But I made a buffer. It should expire more slowly than react.

[mindplay-dk]

Same problem as before, sorry.

It's not random - I have exact steps to recreate the problem:

• "Create 1,000 rows"
• "Append 1,000 rows" x 3
• "Clear"
• "Create 10,000 rows"
• "Update every 10th row" x 3
• "Swap rows" 💣

It consistently freezes up moments after the last click on "Swap Rows".

You actually see the log message in the console before it freezes - and there's a moment after that where the browser is still responsive: table rows still highlight if you move the mouse over the table immediately after pressing "Swap Rows".

My guess is the loop somehow doesn't end after "Swap Rows" - it keeps going for some reason... I'm betting you could set a breakpoint in exactly the right place, you'd be able to see what it's doing after it completes the "Swap Rows" operation?

[yisar]

Today's research results, I have found the cause of memory leaks, which from dom and reconciler.I still need some time.

[mindplay-dk]

I wish I could be of more help, but I honestly don't understand all the details. 😌

[yisar]

Good news, I have fixed this bug now. You can check the latest code.

Now I'm trying to explain why.

When we remove the elements, I find that we will skip the updates of buttons, which causes the events of buttons to not be removed, and eventually leads to memory leakage.

Now it works well, including scheduler and reconciler.

[mindplay-dk]

I'm sorry, I haven't had a chance to look at your work in the past few days.

I just checked current master with the benchmark, and I'm afraid it doesn't work at all now - pressing the create or append buttons just adds a single broken-looking table row, and there are no errors in the console...

I don't know how come the tests are passing? (The scheduler of course works differently under test, because planWork uses a different implementation under test, I don't know if maybe that affects it?)

It looks you introduced a call to setTimeout in testUpdates - I'm not sure why. It's really hard to track what else has changed in the tests because code was reformatted and so many changes were made and then removed again, so I don't know what else was changed... Maybe consider rolling back the test to see if an older version of it still passes?

[yisar]

In the benchmark, only one line was added because I used a while loop for commitWork, which may not save variables in the stack. I have no idea for it now.

You can change your code here, move it inside the Component, such as here

Also you can check the benchmark demo, It works well.

And for the tests, I only change the testUpdates with setTimeout 0, because useEffect now is not run after DOM operation, It is more like useLayoutEffect, For now, I use setTimeout to ensure that it always executes after DOM operation.

[mindplay-dk]

Also you can check the benchmark demo, It works well.

The one in your demo folder?

I'm talking about Krause's benchmark - and it looks similar to the one in your demo folder, it just doesn't work anymore. This is the one I've been testing with. I found the crashing/freezing issues while running this. Those issues aside, it was able to render before, and now doesn't work at all.

Maybe try it out and see what you make of it? I don't know why it shouldn't work. There are not errors in the console when pressing the "create rows" button, it just doesn't work anymore.

For now, I use setTimeout to ensure that it always executes after DOM operation.

Would it make more sense to just use useLayoutEffect in testUpdates? It should work as before then?

[yisar]

1. The reason why benchmark doesn't work is that I refactor commitwork. To save memory, I use the while loop, so there is no way to save external variables in the stack, so you need to move the external JSX to the internal component.

2. Before I implement the async useeffect, I must use setTimeout to ensure that I get the correct result after DOM operation.

[yisar]

Look at this line, this is why benchmark not work, just move it inner component.
https://github.com/132yse/fre/blob/master/demo/benchmark/src/main.jsx#L105
Due to network, I can't clone this project and can't provide PR, but it's just the difference in this line. Stare at it.

[yisar]

Hey, I created a PR, please check it: mindplay-dk/js-framework-benchmark#1

[yisar]

I've fixed all bugs now. I hope this is the last time. benchmark is works well now.

[mindplay-dk]

Benchmark confirmed: no stalling or freezing, produces expected results! 😀🎉

I do believe this introduced a new issue with useEffect - but lets regard this issue as closed, and I will open a separate issue for that.

Good work! 🙂

[yisar]

The problem of useeffect is here: #87