Commit Graph

19 Commits

Author SHA1 Message Date
Oleksandr Melnykov 23429330a6 Back out "Roll out turbo_module_binding_mode experiment"
Summary: Changelog: [Internal]

Reviewed By: jpporto

Differential Revision: D38666524

fbshipit-source-id: af5b1cf2d2db505341ce0992401cb68909e1395b
2022-08-12 12:41:08 -07:00
Pieter De Baets 1a8ce7a26a Roll out turbo_module_binding_mode experiment
Summary:
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.

Changelog: [Internal]

Reviewed By: NickGerleman

Differential Revision: D38355134

fbshipit-source-id: 59253091412d0c6827ad7a4b1ac7dc0c7fe89cc2
2022-08-10 04:54:25 -07:00
Pieter De Baets 1b6584b9f5 Fix TurboModule binding improvements for TurboCxxModule
Summary:
TurboCxxModule doesn't use the the default JSI getter that TurboModule offers, and has custom behaviour for `getConstants` which broke the I18nAssets module in the binding experiment.

Changelog: [Internal]

Reviewed By: ryancat

Differential Revision: D37030917

fbshipit-source-id: 187f159abc76f792ad2c7045dc2852d216ea978d
2022-06-09 17:25:24 -07:00
Pieter De Baets 5ae53cc051 Experiment with HostFunction caching in TurboModules
Summary:
Enables two new experiments (and the current behaviour as default) to speed up access to TurboModule methods from JS.

1) HostObject - Current behaviour
2) Prototype - Connect the TM HostObject via `__proto__`, and cache any methods accessed on the wrapper object.
3) Eager - Eagerly store all methods on the wrapper object, do not expose the HostObject to JS at all (TurboModules no longer need to be HostObjects in this scenario)

Changelog: [Internal]

Reviewed By: JoshuaGross, rubennorte, mdvacca

Differential Revision: D36590018

fbshipit-source-id: c9565eb239eb6aeee0f06b581ff8cd72a92073fc
2022-05-25 07:46:21 -07:00
Pieter De Baets d5045252f8 Cleanup TurboModuleBinding
Summary:
* Make constructor private, all access is through install()
* Use nullability of longLivedObjectCollection_ instead of separate bool disableGlobalLongLivedObjectCollection_

Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D36592492

fbshipit-source-id: d65e779e1ac9fbe121937c5a20763aefcd589795
2022-05-25 07:46:21 -07:00
Pieter De Baets a897314f82 Cleanup TurboModule constructor and headers
Summary:
Avoid copying of std::string and pass std::shared_ptr by reference where possible.

Changelog: [Internal]

Reviewed By: appden

Differential Revision: D36311151

fbshipit-source-id: b0cc791e5eb8353c172d256c69b166d2bdd0db27
2022-05-12 05:49:01 -07:00
Scott Kyle 6a9497dbbb Move some classes to new bridging library (#33413)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33413

This moves `CallbackWrapper` and `LongLivedObject` into a new "bridging" library. This library is mostly intended for use by the native module system, but can also be used separately to "bridge" native and JS interfaces through higher-level (and safer) abstractions than relying JSI alone.

Changelog:
Internal

Reviewed By: christophpurrer

Differential Revision: D34723341

fbshipit-source-id: 7ca8fa815537152f8163920513b90313540477e3
2022-03-11 12:47:51 -08:00
Arthur Kushka 009d80bf5a Dropped using namespace from TurboModuleUtils.h
Summary:
using namespace in header file is a bad practice due to many reasons as well as discouraged by `-Wheader-hygiene` compiler flag which is default for many apps

https://stackoverflow.com/questions/5849457/using-namespace-in-c-headers

Changelog:
[General][Fixed] - Fixed compilation warning due to `using namespace` being used as part of header

Reviewed By: nlutsenko

Differential Revision: D34788523

fbshipit-source-id: 2a50fbf2ac3371ff5670c600c7f5ad9055060ad2
2022-03-11 06:56:10 -08:00
Nikita Lutsenko 1f87729697 rn | cxx | Move the definitions of TurboModule virtual methods to declaration, to allow for use in context with RTTI.
Summary:
Not having this disallows including turbo module and extending in places where RTTI is enabled.
There is no additional includes or implementation changes - it merely allows for things to nicely link with other libraries.

Changelog: [General][Fixed] - Allow including TurboModule.h in mixed rtti/no-rtti environment, even if TurboModule.h/cpp is compiled without RTTI.

Reviewed By: appden

Differential Revision: D34637168

fbshipit-source-id: 2e5d9e546bdc5652f06436fec3b12f1aa9daab05
2022-03-04 19:04:36 -08:00
Andres Suarez 8bd3edec88 Update copyright headers from Facebook to Meta
Reviewed By: aaronabramov

Differential Revision: D33367752

fbshipit-source-id: 4ce94d184485e5ee0a62cf67ad2d3ba16e285c8f
2021-12-30 15:11:21 -08:00
Ramanpreet Nara 32bfd7a857 Stop sharing LongLivedObjectCollection with the bridge
Summary:
## Context
Previously, when you'd call TurboModule methods with JavaScript callbacks, we'd [store the callbacks](https://www.internalfb.com/code/fbsource/[c503ff1b38621aebca87b2bbebeae088b01886c4]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm?lines=173%2C248-249) into [this global LongLivedObjectCollection collection](https://www.internalfb.com/code/fbsource/[c503ff1b38621aebca87b2bbebeae088b01886c4]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleUtils.h?lines=65). Then, when React Native's JavaScript VM got torn down, we'd [clear the global collection](https://www.internalfb.com/code/fbsource/[e26f476ce208c578f05b1edb7639d1dad5612c7d]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.cpp?lines=49), which would ensure that we deleted all held jsi::Functions, before deleting the jsi::Runtime.

## Problem
With bridgeless mode enabled, there can be two TurboModule systems. Further, it is possible to tear down bridgeless mode, or the bridge, without tearing down the other initialization infra. In this scenario, the jsi::Function for the other initialization infra would also get deleted, which could lead to mysterious problems.

## Fix
In this diff, I refactored the jsi::Function cleanup in the TurboModule system. Now, there are 3 modes:
- kGlobalScope: Everything works as it did before
- kRCTGlobalScopeUsingRetainJSCallback: We still use the global LongLivedObjectCollection, but we do it through invoking a block passed to every ObjCTurboModule by the TurboModuleManager. This group exists to assess the impact of having each TurboModule retain/use the block. I suspect this will be negligible, but it'd be good to have actual data to back this claim.
- kRCTTurboModuleManagerScope: Every TurboModule uses a LongLivedObjectCollection that is owned by its TurboModuleManager. This should effectively fix the problem I outlined above.

Changelog: [Internal]

Reviewed By: p-sun

Differential Revision: D30019833

fbshipit-source-id: da50d884c7e37190107f570d8ed70eeda7d9ae83
2021-08-02 11:22:22 -07:00
Joshua Gross 3d1afbbda3 destroy callbacks even if they aren't called, when java object is destroyed
Summary:
JSI callbacks are only destroyed if the callback is called. If the callback is never called, we're potentially leaking a lot of callbacks.

To mitigate this, we add a wrapper object that is owned by the std::function. Whenever the std::function is destroyed, the wrapper is destroyed and it deallocates the callback as well.

Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D27436402

fbshipit-source-id: d153640d5d7988c7fadaf2cb332ec00dadd0689a
2021-04-01 16:28:26 -07:00
Andrew Coates 81c895fb3f Fix various C++ warnings (#31002)
Summary:
Fix warnings about implicit type truncation.

## Changelog

[Internal] [Fixed] - Fix various C++ warnings

Pull Request resolved: https://github.com/facebook/react-native/pull/31002

Test Plan:
Almost all the changes here are simply making explicit conversions which are already occurring.  With the exception of a couple of constants being changed from doubles to floats.

With these changes I am able to remove a bunch of warning suppressions in react-native-windows.

Reviewed By: shergin

Differential Revision: D26900502

Pulled By: rozele

fbshipit-source-id: d5e415282815c2212a840a863713287bbf118c10
2021-03-10 12:39:12 -08:00
Ramanpreet Nara a156ee9b73 Delete JS TurboModule Codegen Gating
Summary: Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D25915171

fbshipit-source-id: b59e21f834a7172055e180eddb9bf15737a6cf0f
2021-01-14 19:14:23 -08:00
Ramanpreet Nara 8ed6659907 Stop forwarding TurboModule schema to TurboModule HostObjects
Summary: Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D25915170

fbshipit-source-id: 2b390428c1f582e55cf3ffe8e691f069bf2fd295
2021-01-14 19:14:23 -08:00
Vladimir Morozov 8aea93022b Remove dependency on Folly in TurboModuleUtils.h (#30672)
Summary:
The TurboModuleUtils.h includes "folly/Optional.h" which is not used and creates an unnecessary dependency on Folly.
In this PR we remove this unnecessary include.

It is required for the https://github.com/microsoft/react-native-windows/pull/6804 where we add an experimental support for the C++ TurboModules. While the C++ TurboModules use the same JSI and TurboModule code defined in react-native, we provide a layer that let them to work over the ABI-safe Microsoft.ReactNative.dll boundary. The RNW Nuget distribution with DLL files includes a few source files to create native/turbo modules that work through the ABI-safe API. The TurboModuleUtils.h is one of such files. By removing the dependency on Folly we reduce requirements for the native module code. After this PR is merged we will remove the fork of the TurboModuleUtils.h  added in https://github.com/microsoft/react-native-windows/pull/6804.

## Changelog

[Internal] [Fixed] - Remove dependency on Folly in TurboModuleUtils.h

Pull Request resolved: https://github.com/facebook/react-native/pull/30672

Test Plan:
The change does not bring any functional changes. It may only affect code compilation where some code may depend on TurboModuleUtils.h when it needs the "folly/Optional.h". The fix is add the `#include <folly/Optional.h>` there explicitly.

I had run the iOS tests and they passed:
```
yarn
pod install in packages\rn-tester
./scripts/objc-test.sh test
```

Reviewed By: mdvacca

Differential Revision: D25758927

Pulled By: fkgozali

fbshipit-source-id: 347d8f6bc333a3df67095ea0dc7221c818432fab
2021-01-04 12:04:58 -08:00
Ramanpreet Nara cb7f3f4499 Setup TurboModule JS Codegen experiment
Summary:
## Android API
```
// Before we initialize TurboModuleManager
ReactFeatureFlags.useTurboModuleJSCodegen = true
```

## iOS API
```
// Before we initialize RCTBridge
RCTEnableTurboModuleJSCodegen(true);
```

## How is the JS Codegen actually enabled?
The above native flags are translated to the following global variable in JavaScript:
```
global.RN$JSTurboModuleCodegenEnabled = true;
```

Then, all our NativeModule specs are transpiled to contain this logic:
```
interface Foo extends TurboModule {
  // ...
}

function __getModuleSchema() {
  if (!global.RN$JSTurboModuleCodegenEnabled) {
    return undefined;
  }

  // Return the schema of this spec.
  return {...};
}

export default TurboModuleRegistry.get<Foo>('foo', __getModuleSchema());
```

Then, in our C++ JavaTurboModule, and ObjCTurboModule classes, we use the TurboModule JS codegen when the jsi::Object schema is provided from JavaScript in the TurboModuleRegistry.get call.

Changelog: [Internal]

Reviewed By: PeteTheHeat

Differential Revision: D24636307

fbshipit-source-id: 80dcd604cc1121b8a69df875bbfc87e9bb8e4814
2020-11-06 13:28:15 -08:00
Ramanpreet Nara 9a7f2b590e Log QPL Events from TM + NM, when Perf. Logging is enabled
Summary:
## Previously
- When TurboModules system was on, we'd only log events from the TurboModules system.
- When TurboModules system was off, we'd only log events from the NativeModule system.

This ultimately gives us less data to analyze both systems in production.

## Changes in This Diff
When perf. logging is on, we'll log events from both systems. Each QPL event now include an annotation of which system the event is coming from. Concretely, this will allow us to see how much of the NativeModule system is being exercised in the TurboModule test group.

Changelog: [Internal]

Reviewed By: hramos

Differential Revision: D24232594

fbshipit-source-id: 7dff57bd74fc7ef744d3e06ff174304f25790456
2020-10-10 02:51:59 -07:00
Kevin Gozali 5be44456f2 TurboModule Android: compile TurboModule C++ Core into ReactAndroid
Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.

New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate

To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23805717

fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9
2020-09-20 14:23:43 -07:00