-
Notifications
You must be signed in to change notification settings - Fork 24.2k
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
Split loadApplicationScript into initializeRuntime and loadBundle #27844
Split loadApplicationScript into initializeRuntime and loadBundle #27844
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I originally suggested making this change if you were going to be splitting up the work that's currently done in loadApplicationScript into two functions, to avoid doing unnecessary initialization work on each subsequent bundle load. However, initializeRuntime
is empty here - are you planning on adding something in a future PR? If not, then I don't think this change is needed, right?
@ejanzer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joeblynch @zamotany Sorry for the late response. Yes, that makes sense - I missed the actual implementations in ProxyExecutor and JSIExecutor when I looked at this. I think this looks good to me, just one change I'd suggest before we try to merge - I think renaming the markers will break perf logging, so we should probably keep those the same.
Thanks for your work on this!
ReactCommon/cxxreact/Instance.cpp
Outdated
@@ -48,7 +48,8 @@ void Instance::initializeBridge( | |||
jsQueue->runOnQueueSync([this, &jsef, jsQueue]() mutable { | |||
nativeToJsBridge_ = std::make_unique<NativeToJsBridge>( | |||
jsef.get(), moduleRegistry_, jsQueue, callback_); | |||
|
|||
// TODO investigate why it has to be async |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why what has to be async? InitializeRuntime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the old leftover, where we make the initial drafts of changes for RN 0.60. When implementing it, we've noticed that the code in NativeToJsBridge::initializeRuntime
has to be run using runOnExecutorQueue
. We haven't investigated more why we have to do it like that, since the code was working as expected and was crashing if runOnExecutorQueue
was not used. This comment can be discarded and we'll remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With some versions of JSC, if you create the runtime on one thread, and then use it on another, GC bugs will cause crashes. That's why this has to be done this way. It's not pretty, but there's not much else to be done if you want to use older versions of iOS. I'm not sure if the android JSC has this bug or not.
ReactCommon/cxxreact/JSExecutor.h
Outdated
@@ -53,10 +53,14 @@ class JSExecutorFactory { | |||
|
|||
class RN_EXPORT JSExecutor { | |||
public: | |||
/** | |||
* Sets all globals in the JS context. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like: "Prepares the JS runtime for React Native by installing global variables. Called once before any JS is evaluated."
@@ -59,8 +59,8 @@ | |||
UNPACKING_JS_BUNDLE_LOADER_CHECK_END, | |||
UNPACKING_JS_BUNDLE_LOADER_EXTRACTED, | |||
UNPACKING_JS_BUNDLE_LOADER_BLOCKED, | |||
loadApplicationScript_startStringConvert, | |||
loadApplicationScript_endStringConvert, | |||
loadBundle_startStringConvert, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only thing that I'm a little bit concerned about - renaming our perf markers could be a breaking change for our perf instrumentation. I think it might be better to keep these the same, even though they won't match the function name anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally valid concert, we'll revert that change.
Thank you @ejanzer for reviewing these PRs! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ejanzer has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
Hey @ejanzer, is there any update on this? Seems to be taking a while, could be due to some internal merge conflicts. |
This pull request was successfully merged by @simka in 6f627f6. When will my fix make it into a release? | Upcoming Releases |
…cebook#27844) Summary: This is the first of three PRs related to enabling multi-bundle support in React Native. More details, motivation and reasoning behind it can be found in RFC [here](react-native-community/discussions-and-proposals#152). Logic responsible for installing globals was pulled out from `loadApplicationScript` to `initializeRuntime` since it should be ran only once, what was left was renamed to `loadBundle`. It's based on dratwas work from [here](https://github.com/callstack/react-native/tree/feat/multibundle/split-load-application), but applied to current `master` to avoid rebasing 3-months old branch and issues that come with that. ## Changelog [Internal] [Changed] - split `loadApplicationScript` into `initializeRuntime` and `loadBundle` to enable multi-bundle support in the future Pull Request resolved: facebook#27844 Test Plan: Initialized new RN app with CLI, set RN to build from source and verified the still app builds and runs OK using code from this branch. Reviewed By: rickhanlonii Differential Revision: D19888605 Pulled By: ejanzer fbshipit-source-id: 24ace48ffe8978796591fe7c6cf53a61b127cce6
…ndle (facebook#27844)" This reverts commit 6f627f6.
…ndle (facebook#27844)" This reverts commit 6f627f6.
…ndle (facebook#27844)" This reverts commit 6f627f6.
* Add nullability checks (#704) * Update RCTCxxBridge.mm * add nullability checks * Revert "Split loadApplicationScript into initializeRuntime and loadBundle (facebook#27844)" This reverts commit 6f627f6. * pod fixes * Revert "Split loadApplicationScript into initializeRuntime and loadBundle (facebook#27844)" This reverts commit 6f627f6. * pod fixes * pod update * pod install * fix libevents and flipper dependencies * flipper updates * disable sonar kit * Revert "Split loadApplicationScript into initializeRuntime and loadBundle (facebook#27844)" This reverts commit 6f627f6. * pod fixes * flipper updates * disable sonar kit * pod install
Summary
This is the first of three PRs related to enabling multi-bundle support in React Native. More details, motivation and reasoning behind it can be found in RFC here.
Logic responsible for installing globals was pulled out from
loadApplicationScript
toinitializeRuntime
since it should be ran only once, what was left was renamed toloadBundle
.It's based on @dratwas work from here, but applied to current
master
to avoid rebasing 3-months old branch and issues that come with that.Changelog
[Internal] [Changed] - split
loadApplicationScript
intoinitializeRuntime
andloadBundle
to enable multi-bundle support in the futureTest Plan
Initialized new RN app with CLI, set RN to build from source and verified the still app builds and runs OK using code from this branch.