drainPreallocateViewsQueue blocks the Android UI thread on the JS thread's executeMount since #58890

Offen
  • Stimmt etwas nicht?
#59,244 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
android, cpp, java, react-native
Bereich
frontend, mobile, performance

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
  1. Apply the reproducer's two patches to main at 202d93931c: the scenes in RNTester's View examples, and a trace section around the drain call.
  2. Build RNTester release for arm64-v8a and open View → "Pre-mount burst: 1200 items".
  3. Record a Perfetto trace of 24 s with sched/sched_switch and the app's view and gfx atrace categories.
  4. Find the FabricUIManager::drainPreallocateViewsQueue slices on the main thread that start during FabricMountingManager::executeMount on mqt_v_js: the main thread sleeps in them until about 0.4 ms before executeMount returns, and they contain no FabricMountingManager::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.

Vorherrschende Sprache
C++
Sterne
127k
Forks
25.4k
Ø Merge
2 T. 9 Std.
Gemergte PRs (30 T.)
91

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus react/react-native

Alle Issues in react/react-native

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.