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

Split loadApplicationScript into initializeRuntime and loadBundle #27844

Conversation

simka
Copy link
Contributor

@simka simka commented Jan 23, 2020

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 to initializeRuntime since it should be ran only once, what was left was renamed to loadBundle.

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 into initializeRuntime and loadBundle to enable multi-bundle support in the future

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.

Copy link

@ejanzer ejanzer left a 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?

@zamotany
Copy link

@ejanzer
initializeRuntime is only empty for the specific executor - RCTObjcExecutor. For other executors like JSIExecutor and ProxyExecutor, initializeRuntime will contain a logic, that should ideally be run only once. We've tried to more some of the logic (that made sense) out from RCTObjcExecutor constructors to it's initializeRuntime, but the app was crashing.

@joeblynch
Copy link

Hey @ejanzer, thanks for taking a look at this PR! Based on @zamotany's comment, do you think this PR is still needed? Also just a heads up, the other PRs that split out the work from the original RFC are up here and here.

Copy link

@ejanzer ejanzer left a 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!

@@ -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
Copy link

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?

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.

Copy link
Contributor

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.

@@ -53,10 +53,14 @@ class JSExecutorFactory {

class RN_EXPORT JSExecutor {
public:
/**
* Sets all globals in the JS context.
Copy link

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,
Copy link

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.

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.

@joeblynch
Copy link

Thank you @ejanzer for reviewing these PRs!

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a 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.

@grabbou
Copy link
Contributor

grabbou commented Feb 26, 2020

Hey @ejanzer, is there any update on this? Seems to be taking a while, could be due to some internal merge conflicts.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by @simka in 6f627f6.

When will my fix make it into a release? | Upcoming Releases

@react-native-bot react-native-bot added the Merged This PR has been merged. label Apr 2, 2020
sasurau4 pushed a commit to sasurau4/react-native that referenced this pull request Apr 15, 2020
…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
HeyImChris added a commit to HeyImChris/react-native-macos that referenced this pull request May 20, 2021
HeyImChris added a commit to HeyImChris/react-native-macos that referenced this pull request May 25, 2021
HeyImChris added a commit to HeyImChris/react-native-macos that referenced this pull request Jun 1, 2021
HeyImChris added a commit to microsoft/react-native-macos that referenced this pull request Jun 1, 2021
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants