Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't bind expiration time to render callback #16715

Closed
wants to merge 8 commits into from

Conversation

acdlite
Copy link
Collaborator

@acdlite acdlite commented Sep 9, 2019

Based on #16663 and #16678

This is a fragile pattern because there's only meant to be a single task per root, running at a single expiration time. Instead of binding the expiration time to the render task, or closing over it, we should determine the correct expiration time to work on using fields we store on the root object itself.

This removes the "return a continuation" pattern from the renderRoot function. Continuation handling is now handled by the wrapper function, which I've renamed from runRootCallback to performWorkOnRoot. That function is merely an entry point to renderRoot, so I've also removed the callback argument.

So to sum up, at at the beginning of each task, performWorkOnRoot determines which expiration time to work on, then calls renderRoot. And before exiting, it checks if it needs to schedule another task.

A FiberRoot can have pending work at many distinct priorities. (Note: we
refer to these levels as "expiration times" to distinguish the concept
from Scheduler's notion of priority levels, which represent broad
categories of work. React expiration times are more granualar. They're
more like a concurrent thread ID, which also happens to correspond to a
moment on a timeline. It's an overloaded concept and I'm handwaving over
some of the details.)

Given a root, there's no convenient way to read all the pending levels
in the entire tree, i.e. there's no single queue-like structure that
tracks all the levels, because that granularity of information is not
needed by our algorithms. Instead we track the subset of information
that we actually need — most importantly, the highest priority level
that exists in the entire tree.

Aside from that, the other information we track includes the range of
pending levels that are known to be suspended, and therefore should not
be worked on.

This is a refactor of how that information is tracked, and what each
field represents:

- A *pending* level is work that is unfinished, or not yet committed.
  This includes work that is suspended from committing.
  `firstPendingTime` and `lastPendingTime` represent the range of
  pending work. (Previously, "pending" was the same as "not suspended.")
- A *suspended* level is work that did not complete because data was
  missing. `firstSuspendedTime` and `lastSuspendedTime` represent the
  range of suspended work. It is a subset of the pending range. (These
  fields are new to this commit.)
- `nextAfterSuspendedTime` represents the next known level that comes
  after the suspended range.

This commit doesn't change much in terms of observable behavior. The one
change is that, when a level is suspended, React will continue working
on the next known level instead of jumping straight to the last pending
level. Subsequent commits will use this new structure for a more
substantial refactor for how tasks are scheduled per root.
Given a FiberRoot, we should be able to determine the next expiration
time that needs to be worked on, taking into account the levels that
are pending, suspended, pinged, and so on.

This removes the `expirationTime` argument from
`scheduleCallbackForRoot`, and renames it to `ensureRootIsScheduled` to
reflect the new signature. The expiration time is instead read from the
root using a new function, `getNextExpirationTimeToWorkOn`.

The next step will be to remove the `expirationTime` argument from
`renderRoot`, too.
This is a fragile pattern because there's only meant to be a single
task per root, running at a single expiration time. Instead of binding
the expiration time to the render task, or closing over it, we should
determine the correct expiration time to work on using fields we
store on the root object itself.

This removes the "return a continuation" pattern from the
`renderRoot` function. Continuation handling is now handled by
the wrapper function, which I've renamed from `runRootCallback` to
`performWorkOnRoot`. That function is merely an entry point to
`renderRoot`, so I've also removed the callback argument.

So to sum up, at at the beginning of each task, `performWorkOnRoot`
determines which expiration time to work on, then calls `renderRoot`.
And before exiting, it checks if it needs to schedule another task.
@acdlite acdlite requested a review from sebmarkbage September 9, 2019 22:42
@@ -494,7 +494,7 @@ describe('ReactSuspenseWithNoopRenderer', () => {
return <Text text="(empty)" />;
}
return (
<Suspense>
<Suspense fallback="Loading...">
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test was testing the wrong thing, because a Suspense without a fallback will result in an error. So what this was actually testing was the "on error, try again at the lowest pending level."

@sizebot
Copy link

sizebot commented Sep 9, 2019

ReactDOM: size: 0.0%, gzip: 0.0%

Details of bundled changes.

Comparing: 9ce8711...09461dc

react-dom

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-dom.profiling.min.js +0.8% +0.8% 115.32 KB 116.27 KB 36.35 KB 36.64 KB NODE_PROFILING
react-dom-server.browser.development.js 0.0% 0.0% 142.1 KB 142.1 KB 37.12 KB 37.12 KB UMD_DEV
ReactDOM-dev.js +0.6% +0.6% 939.12 KB 944.86 KB 207.42 KB 208.75 KB FB_WWW_DEV
react-dom-server.browser.production.min.js 0.0% 0.0% 19.8 KB 19.8 KB 7.36 KB 7.36 KB UMD_PROD
react-dom-test-utils.production.min.js 0.0% -0.0% 11.18 KB 11.18 KB 4.15 KB 4.15 KB UMD_PROD
react-dom-unstable-fizz.browser.production.min.js 0.0% 🔺+0.1% 1.2 KB 1.2 KB 701 B 702 B UMD_PROD
react-dom-test-utils.production.min.js 0.0% -0.1% 10.95 KB 10.95 KB 4.09 KB 4.09 KB NODE_PROD
react-dom-unstable-fizz.browser.production.min.js 0.0% 🔺+0.2% 1.04 KB 1.04 KB 632 B 633 B NODE_PROD
react-dom.development.js +0.6% +0.6% 914.99 KB 920.76 KB 207.39 KB 208.69 KB UMD_DEV
react-dom.production.min.js 🔺+0.8% 🔺+0.6% 111.71 KB 112.58 KB 36.02 KB 36.25 KB UMD_PROD
react-dom.profiling.min.js +0.9% +0.6% 115.12 KB 116.12 KB 37.08 KB 37.32 KB UMD_PROFILING
react-dom.development.js +0.6% +0.6% 909.08 KB 914.85 KB 205.71 KB 207.01 KB NODE_DEV
react-dom-server.node.development.js 0.0% 0.0% 139.05 KB 139.05 KB 36.34 KB 36.34 KB NODE_DEV
react-dom.production.min.js 🔺+0.8% 🔺+0.7% 111.68 KB 112.55 KB 35.39 KB 35.62 KB NODE_PROD
react-dom-server.node.production.min.js 0.0% 0.0% 20.13 KB 20.13 KB 7.5 KB 7.51 KB NODE_PROD
ReactDOM-prod.js 🔺+1.1% 🔺+0.8% 372 KB 376 KB 68.15 KB 68.67 KB FB_WWW_PROD
ReactDOM-profiling.js +1.2% +0.8% 377.55 KB 382.02 KB 69.21 KB 69.79 KB FB_WWW_PROFILING
react-dom-server.browser.development.js 0.0% 0.0% 138.04 KB 138.04 KB 36.11 KB 36.11 KB NODE_DEV
react-dom-server.browser.production.min.js 0.0% 0.0% 19.73 KB 19.73 KB 7.34 KB 7.34 KB NODE_PROD
react-dom-unstable-native-dependencies.development.js 0.0% 0.0% 60.71 KB 60.71 KB 15.85 KB 15.85 KB UMD_DEV
react-dom-unstable-native-dependencies.development.js 0.0% 0.0% 60.39 KB 60.39 KB 15.72 KB 15.72 KB NODE_DEV
react-dom-unstable-fizz.node.development.js 0.0% +0.1% 3.87 KB 3.87 KB 1.51 KB 1.51 KB NODE_DEV
react-dom-unstable-native-dependencies.production.min.js 0.0% 0.0% 10.49 KB 10.49 KB 3.58 KB 3.58 KB NODE_PROD
react-dom-unstable-fizz.node.production.min.js 0.0% 🔺+0.1% 1.1 KB 1.1 KB 667 B 668 B NODE_PROD

react-art

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-art.development.js +0.9% +0.9% 657.27 KB 662.96 KB 143.12 KB 144.34 KB UMD_DEV
react-art.production.min.js 🔺+0.8% 🔺+0.6% 101.93 KB 102.73 KB 31.17 KB 31.35 KB UMD_PROD
react-art.development.js +1.0% +1.0% 587.95 KB 593.63 KB 125.67 KB 126.9 KB NODE_DEV
react-art.production.min.js 🔺+1.2% 🔺+1.1% 66.94 KB 67.74 KB 20.4 KB 20.62 KB NODE_PROD
ReactART-dev.js +0.9% +1.0% 603.18 KB 608.85 KB 125.4 KB 126.64 KB FB_WWW_DEV
ReactART-prod.js 🔺+1.7% 🔺+1.3% 225.92 KB 229.8 KB 38.47 KB 38.97 KB FB_WWW_PROD

react-native-renderer

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
ReactNativeRenderer-prod.js 🔺+1.5% 🔺+1.1% 269.9 KB 273.9 KB 46.26 KB 46.76 KB RN_OSS_PROD
ReactNativeRenderer-profiling.js +1.7% +1.3% 278.4 KB 283.09 KB 47.8 KB 48.41 KB RN_OSS_PROFILING
ReactFabric-prod.js 🔺+1.5% 🔺+1.1% 261.69 KB 265.69 KB 44.95 KB 45.44 KB RN_OSS_PROD
ReactFabric-profiling.js +1.8% +1.3% 270.44 KB 275.2 KB 46.47 KB 47.06 KB RN_OSS_PROFILING
ReactFabric-dev.js +0.8% +0.8% 742.49 KB 748.2 KB 156.9 KB 158.22 KB RN_FB_DEV
ReactFabric-prod.js 🔺+1.5% 🔺+1.1% 261.7 KB 265.7 KB 44.96 KB 45.46 KB RN_FB_PROD
ReactNativeRenderer-dev.js +0.8% +0.9% 735.89 KB 741.6 KB 155.72 KB 157.05 KB RN_OSS_DEV
ReactFabric-profiling.js +1.8% +1.3% 270.44 KB 275.2 KB 46.48 KB 47.07 KB RN_FB_PROFILING
ReactNativeRenderer-dev.js +0.8% +0.9% 736.05 KB 741.76 KB 155.81 KB 157.14 KB RN_FB_DEV
ReactNativeRenderer-prod.js 🔺+1.5% 🔺+1.1% 269.9 KB 273.9 KB 46.27 KB 46.77 KB RN_FB_PROD
ReactNativeRenderer-profiling.js +1.7% +1.3% 278.39 KB 283.08 KB 47.81 KB 48.42 KB RN_FB_PROFILING
ReactFabric-dev.js +0.8% +0.8% 742.32 KB 748.03 KB 156.83 KB 158.15 KB RN_OSS_DEV

react-test-renderer

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
ReactTestRenderer-dev.js +0.9% +1.0% 614.27 KB 619.94 KB 127.81 KB 129.06 KB FB_WWW_DEV
react-test-renderer-shallow.production.min.js 0.0% 🔺+0.1% 11.41 KB 11.41 KB 3.53 KB 3.53 KB UMD_PROD
react-test-renderer-shallow.production.min.js 0.0% 🔺+0.1% 11.55 KB 11.55 KB 3.62 KB 3.62 KB NODE_PROD
react-test-renderer.development.js +0.9% +1.0% 601.29 KB 606.98 KB 128.44 KB 129.69 KB UMD_DEV
react-test-renderer.production.min.js 🔺+1.2% 🔺+0.9% 68.88 KB 69.68 KB 21.18 KB 21.38 KB UMD_PROD
react-test-renderer.development.js +1.0% +1.0% 596.63 KB 602.31 KB 127.24 KB 128.49 KB NODE_DEV
react-test-renderer.production.min.js 🔺+1.2% 🔺+1.0% 68.57 KB 69.37 KB 20.9 KB 21.1 KB NODE_PROD

react-reconciler

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-reconciler.development.js +1.0% +1.0% 586.59 KB 592.36 KB 124.37 KB 125.67 KB NODE_DEV
react-reconciler.production.min.js 🔺+1.2% 🔺+1.1% 68.94 KB 69.79 KB 20.44 KB 20.67 KB NODE_PROD
react-reconciler-reflection.development.js 0.0% 0.0% 19.25 KB 19.25 KB 6.33 KB 6.33 KB NODE_DEV
react-reconciler-persistent.development.js +1.0% +1.1% 583.6 KB 589.36 KB 123.1 KB 124.4 KB NODE_DEV
react-reconciler-persistent.production.min.js 🔺+1.2% 🔺+1.1% 68.95 KB 69.8 KB 20.45 KB 20.67 KB NODE_PROD

Generated by 🚫 dangerJS against 09461dc

@acdlite acdlite force-pushed the dont-bind-expiration-time branch 3 times, most recently from a67ce79 to ec600a9 Compare September 10, 2019 01:39
@acdlite acdlite force-pushed the dont-bind-expiration-time branch from ec600a9 to 9a54113 Compare September 10, 2019 01:45
@@ -422,7 +422,10 @@ exports[`ReactDebugFiberPerf warns if an in-progress update is interrupted 1`] =
`;

exports[`ReactDebugFiberPerf warns if async work expires (starvation) 1`] = `
"⚛ (Committing Changes)
"⚛ (React Tree Reconciliation: Completed Root)
⚛ Foo [mount]
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was actually wrong before, because it improperly dropped the measurements from the render phase.

Copy link
Contributor

@Jessidhia Jessidhia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this fixes #16632 🤔

if (expirationTime !== Sync) {
// Since we know we're in a React event, we can clear the current
// event time. The next update will compute a new event time.
currentEventTime = NoWork;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a React event?

(is any queued async update considered an "event"?)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "event" here refers to a scheduled callback with the scheduler. I.e. clean stack.

If the work-in-progress root already suspended with a delay, then the
current render definitely won't finish. We should interrupt the render
and switch to the incoming update.
@acdlite acdlite force-pushed the dont-bind-expiration-time branch 4 times, most recently from cc83dca to 0e92ca1 Compare September 10, 2019 03:35
// try restarting now instead.
root.lastPingedTime = expirationTime;
prepareFreshStack(root, expirationTime);
return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If lastPingedTime === expirationTime then I wouldn't expect there to be a callback already scheduled, right? So how does this pick up work back up?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const nextTime = getNextRootExpirationTimeToWorkOn(root);
if (nextTime !== NoWork && nextTime !== expirationTime) {
// There's additional work on this root.
return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't really hurt to schedule a callback that is just going to get canceled, right? Maybe it's ok to let it schedule a callback just in case we don't get called for a while to other work, we might as well commit?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// We should prefer to render the fallback of at the last suspended
// level. Ping the last suspended level to try rendering it again.
root.lastPingedTime = lastSuspendedTime;
return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm paranoid about these not having a callback scheduled and us stalling.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put ensureRootIsScheduled in the finally block of performWorkOnRoot to try to account for this.

I think it could theoretically happen for some of the early flush paths, which bypass performWorkOnRoot. But since they bypass performWorkOnRoot, they also won’t cause an existing callback to be canceled.

Similar to the previous commit, if we suspend with a delay, and
something in the return path has a pending update, we should abort
the current render and switch to the update instead.
@acdlite acdlite force-pushed the dont-bind-expiration-time branch from 0e92ca1 to 2d93c7e Compare September 10, 2019 20:03
Instead of backtracking the return path. The main advantage over the
backtracking approach is that we don't have to backtrack from the source
fiber. (The main disadvantages are that it requires another module-level
variable, and that it could include updates from unrelated
sibling paths.)
@acdlite
Copy link
Collaborator Author

acdlite commented Sep 10, 2019

@sebmarkbage Regarding your paranoia that we'll neglect to schedule a callback, I opened a follow-up PR that tries to prevent a refactor hazard: #16743

@acdlite
Copy link
Collaborator Author

acdlite commented Sep 11, 2019

Closed by ab4951f

@acdlite acdlite closed this Sep 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants