drainPreallocateViewsQueue blocks the Android UI thread on the JS thread's executeMount since #58890
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 55/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 領域
- frontend, mobile, performance
調査の方向性
Start with FabricMountingManager.cpp around drainPreallocateViewsQueue and executeMount, then read the call site in FabricUIManager.java and the linked reproducer’s README. Reproduce the empty-queue lock wait with the provided Perfetto steps and compare against the pre-#58890 behavior. Done when empty drains no longer wait behind executeMount and the supplied Android scenes show no such waits.
索引モデルが issue の本文から書いたものです。
説明
Description
Since #58890, FabricMountingManager::drainPreallocateViewsQueue takes allocatedViewsMutex_ on every call, whether or not anything is queued (FabricMountingManager.cpp). FabricUIManager calls it at the start of every frame callback (FabricUIManager.java), and executeMount holds the same mutex on the JS thread across a transaction's mutations (FabricMountingManager.cpp). So a frame that starts while the JS thread builds a large commit's mount items waits on the UI thread until they are built, with nothing to pre-allocate. Before #58890 the drain took the mutex once per queued view, so an empty queue never waited; 0.88.0 still does that.
Release RNTester from main at 202d93931c, with the reproducer's scenes: 600 or 2400 views mounted and unmounted in turn every 1.5 s beside a native-driven Animated.spring, 2400 at each fling of a horizontal ScrollView, and 2400 over 160 translucent full-window views.
| Galaxy S23, Android 14, 120 Hz | RedMagic NX809J, Android 16, 120 Hz | Mi MIX 3, Android 10, 60 Hz | |
|---|---|---|---|
| waits of 1 ms or more in the drain | 12 in 50 mounts | 2 in 51 mounts | 26 in 48 mounts |
with nothing queued, while mqt_v_js was in executeMount |
12, 1.2–7.9 ms | 2, 1.6 and 1.9 ms | 24, 1.0–7.0 ms |
On the S23 the two longest waits made their frames 9.3 and 8.8 ms long, past the next vsync. The spring and fling scenes built from main at b8ec87e457, before #58890, never waited 1 ms or more in 36 mounts on the S23; at 202d93931c they waited 5 times in 36.
Could the drain return before taking the mutex when nothing is queued, as it did before #58890? A drain with views still queued would wait for executeMount as it did then.
Steps to reproduce
- Apply the reproducer's two patches to
mainat 202d93931c: the scenes in RNTester's View examples, and a trace section around the drain call. - Build RNTester release for
arm64-v8aand open View → "Pre-mount burst: 1200 items". - Record a Perfetto trace of 24 s with
sched/sched_switchand the app'sviewandgfxatrace categories. - Find the
FabricUIManager::drainPreallocateViewsQueueslices on the main thread that start duringFabricMountingManager::executeMountonmqt_v_js: the main thread sleeps in them until about 0.4 ms beforeexecuteMountreturns, and they contain noFabricMountingManager::preallocateRegisteredView.
Expected: with nothing queued, the drain returns at once, as it did before #58890.
Actual: the main thread waits in the drain for the JS thread's executeMount, 1.2–7.9 ms on the S23 (the table above).
React Native Version
nightly (main at 202d93931c)
Affected Platforms
Runtime - Android
Areas
Fabric - The New Renderer
Output of npx @react-native-community/cli info
System:
OS: Windows 11 10.0.26200
CPU: "(32) x64 AMD Ryzen 9 9950X3D 16-Core Processor "
Memory: 166.93 GB / 255.67 GB
Binaries:
Node:
version: 26.8.1
path: C:\Program Files\nodejs\node.EXE
Yarn:
version: 1.22.22
path: ~\AppData\Roaming\npm\yarn.CMD
npm:
version: 12.0.1
path: C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK:
API Levels:
- "33"
- "35"
- "35"
- "35"
- "36"
- "37"
Build Tools:
- 35.0.0
- 36.0.0
- 36.1.0
- 37.0.0
System Images:
- android-26 | Google APIs Intel x86_64 Atom
- android-28 | Google APIs Intel x86_64 Atom
- android-29 | Google APIs Intel x86_64 Atom
- android-30 | Google APIs Intel x86_64 Atom
- android-31 | Google APIs Intel x86_64 Atom
- android-32 | Google APIs Intel x86_64 Atom
- android-33 | Google APIs Intel x86_64 Atom
- android-34 | Google APIs Intel x86_64 Atom
- android-35 | Google APIs Intel x86_64 Atom
- android-36.1 | Google Play Intel x86_64 Atom
- android-36.1 | Pre-Release 16 KB Page Size Google Play Intel x86_64 Atom
- android-37.0 | Google APIs Intel x86_64 Atom
Android NDK: Not Found
Windows SDK: Not Found
IDEs:
Android Studio: AI-252.27397.103.2522.14617522
Visual Studio: Not Found
Languages:
Java:
version: 17.0.20.1
path: /c/Program Files/Microsoft/jdk-17.0.20.101-hotspot/bin/javac
Ruby: Not Found
npmPackages:
"@react-native-community/cli": Not Found
react: Not Found
react-native: Not Found
react-native-windows: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: false
newArchEnabled: false
iOS:
hermesEnabled: Not found
newArchEnabled: Not found
Run in the React Native checkout I built RNTester from; the builds are main at 202d93931c and b8ec87e457.
Stacktrace or Logs
No crash. Galaxy S23, Android 14, 120 Hz; release RNTester from main at 202d93931c,
View → "Pre-mount burst: 1200 items", one commit:
mqt_v_js FabricMountingManager::executeMount 7.64 ms
main Choreographer#doFrame 8.83 ms, frames 8.34 ms apart
FabricUIManager::drainPreallocateViewsQueue 7.19 ms, asleep for 7.16 ms of it,
no preallocateRegisteredView in it
main asleep from 0.09 ms after executeMount began until 0.40 ms before it returned
MANDATORY Reproducer
https://github.com/YevheniiKotyrlo/react-native-evidence/tree/main/preallocation-drain-lock-wait
Screenshots and Videos
The scenes, the builds, how they were traced and every wait are on this page.
- 主要言語
- C++
- スター
- 127k
- フォーク
- 25.4k
- 平均マージ
- 2日 9時間
- マージ済み PR(30日)
- 91
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
react/react-native のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
react/react-native#59722 ·
メンテナーはふだん 2 日以内に返信
-
Android: new WebSocket() crashes the app for a URL that OkHttp or java.net.URI rejects対応中かも @sorinc03 が 1 日前に担当しました。 オープン🌐Networking Needs: Author Feedback Needs: Repro Platform: Android
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
react/react-native#59704 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
react/react-native#59694 ·
メンテナーはふだん 2 日以内に返信
-
Android autolinking keeps a stale autolinking.json when only bun.lock changes, since bun.lock isn't in the default lockFiles対応中かも @lazerg が 3 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
react/react-native#59693 ·
メンテナーはふだん 2 日以内に返信
-
Image.resolveAssetSource's TypeScript declaration drops the null it returns for an unknown asset対応中かも @Hassan1305 が 3 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
react/react-native#59648 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
react/react-native の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
cython/cython#8110 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
ROCm/rocm-systems#14923 ·
メンテナーはふだん 2 日以内に返信
-
arrays asr pass bug ICE intrinsic medium priority
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
Area: World-Readiness
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
microsoft/calculator#2522 ·
-
missing `catch.hpp`オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
microsoft/inflatelib#34 · コメント 1 件 ·