Summary:
The hermes profiler doesn't work currently, I tracked down the problem to a couple of things.
- Need to call `registerForProfiling` to enable profiling for a specific runtime. I added the call at the same place where we enable the debugger.
- `runInExecutor` didn't work and call its callback. Not sure exactly why, but using `executor_->add` like we do in a lot of other places to run code on the executor works.
- `GetHeapUsageRequest` seems to cause some deadlocks. JS contexts were not detected reliably, I suspect this is related to deadlocks when trying to run on inspector executor. `GetHeapUsageRequest` doesn't actually need any data from the inspector so there is no need to run it on that queue. To fix it I moved the call to use `runInExecutor` instead.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Fix hermes profiler
Pull Request resolved: https://github.com/facebook/react-native/pull/34129
Reviewed By: cortinico
Differential Revision: D37669469
Pulled By: philIip
fbshipit-source-id: 6cf3b2857ac60b0a1518837b9c56b9c093ed222f
Summary:
The `RuntimeAdapter` may be used after `disableDebugging` has been called. To ensure the `RuntimeAdapter` is alive long enough for this use, the Inspector should continue to control `RuntimeAdapter`'s lifetime (which is currently done via a `unique_ptr` that's moved into the Inspector).
Callers need a way to identify the `RuntimeAdapter` after it has been moved into the Inspector so that debugging can be disabled via `disableDebugging`.
This could be done by switching from a `unique_ptr` to a `shared_ptr` (so the caller can keep a copy), but consumers don't really have a reason to hang onto the `RuntimeAdapter` instance. Instead, leave the `RuntimeAdapter` inside a `unique_ptr`, and have consumers use a token to identify instances.
Update all consumers of this API to use this new token interface.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38513256
fbshipit-source-id: 33580747cd8365d25dbddbe289f0c41141e3bc6a
Summary:
Make the interface to enable/disable debugging symmetrical; both enabling and disabling are done by passing in a reference to the RuntimeAdapter.
Doing so requires moving ownership of the RuntimeAdapter, so each caller (java2js, arfx engine, React Native, react-native-github, and venice) has been updated to own their adapter.
Additionally, the two implementations of the Inspector connection (react-native-github and arfx engine) have been updated to expect and use the new argument.
`Connection::getRuntime` could be removed and replaced with calls to `Connection::getRuntimeAdapter::getRuntime`. I've left that choice to a followup diff, as this one is getting messy enough as it is.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38242964
fbshipit-source-id: f2a3354f9d424b203a76d2c15122a6515a0926f2
Summary:
Changelog: [Internal]
Provide a `HermesRuntime` from the `RuntimeAdapter` (instead of a decorated Hermes runtime).
As the Inspector can now directly access the `HermesRuntime` (which exposes access to the debugger), `RuntimeAdapter::getDebugger` is no longer necessary; remove it.
Reviewed By: jpporto
Differential Revision: D38050821
fbshipit-source-id: fa83165a9348bdff0dce1b04ec1afb81d2b1c3e2
Summary:
Changelog: [Internal]
Make runtime use more consistent, always using the same undecorated runtime. This prevents the previous mixing of decorated and undecorated runtimes.
Reviewed By: jpporto
Differential Revision: D38035166
fbshipit-source-id: 81929e42ccc4de6d5c5c09ee7ee31f055af82735
Summary:
The RN Hermes Inspector keeps a mapping of pageId to
Connection. This mapping is created in the call to
enableDebugging. Later, when disableDebugging is invoked,
the inspector will iterate over the pageId to Connection map
to find which page to is being disabled.
The DecoratedRuntime enables debugging on construction, and
disables on destruction. When disabling debugging, the
DecoratedRuntime then passes the "naked" hermesRuntime,
which in turn gets checked against all connections' runtimes.
It turns our that ```HermesExecutorRuntimeAdapter::getRuntime```
returns the runtime **wrapped** by the DecoratedRuntime, and
not hermesRuntime itself.
This means that no connections match the request for
disabling debugging. Which means the Connection never
gets deleted, which in turns keep its underlying adapter (in
this case, the ```HermesRuntimeExecutorAdapter```) alive,
which has a shared_ptr to the runtime wrapped by the DecoratedRuntime.
Other than effectively leaking this connection (and thus the runtime),
this also causes an issue when the app tries to re-load the page -- at
which point the inspector will remove the old entry from the page to
connection mapping, thus initiating the destruction of the (leaked)
Runtime in a thread other than the thread that created the runtime.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37809467
fbshipit-source-id: e73caa357a300a0d48e69aa3a1a8b00a97519f24
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
Adds CMake files to configure hermes-executor build, with the same setup as we have in Android.mk
Changelog: [Internal] - CMake build config for hermes executor
Reviewed By: cortinico
Differential Revision: D34811909
fbshipit-source-id: 2df6dbaf46131db87a25e26c83b38ba44f29d1d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33396
This commit fully unplugs the `ReactAndroid` from using hermes from the NPM package and plugs the usage of Hermes via the `packages/hermes-engine` Gradle build.
I've used prefab to share the .so between the two builds, so we don't need any extra machinery to make this possible.
Moreover, I've added a `buildHermesFromSource` property, which defaults to false when RN is imported, but is set to true when RN is opened for local development. This should allow us to distribute the `react-native` NPM package and users could potentially toggle which source to use (but see below).
Changelog:
[Android] [Changed] - Build Hermes from Source
Reviewed By: hramos
Differential Revision: D34389875
fbshipit-source-id: 107cbe3686daf7607a1f0f75202f24cd80ce64bb
Summary:
I've been seeing a couple crashes related to missing hermes-executor-common.so, seems to happen on specific android versions, but can't repro. I investigated this so file more and noticed it is incorrectly linked as a static library here https://github.com/facebook/react-native/blob/b8f415eb6cdc0e0e7a7413b6f9defdcee304d9e8/ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/Android.mk#L20. There doesn't seem to be any reason for this to be a shared lib so I changed it to be compiled as a static lib.
## Changelog
[Android] [Fixed] - Make hermes-executor-common a static lib
Pull Request resolved: https://github.com/facebook/react-native/pull/32683
Test Plan:
- Verify there is no more hermes-executor-common-{release,debug}.so
- Test locally in an app to make sure it build and run properly.
- Verify that the crash happening on play store pre-launch report doesn't happen anymore.
Reviewed By: ShikaSD
Differential Revision: D32754968
Pulled By: cortinico
fbshipit-source-id: cb57e2d81edb4cbdb1f003dab45c53e594a5a62a
Summary:
Ship libjsi as a standalone dynamic library. This prevents problems
with exception handling caused by duplicate typeinfo across multiple
shared libs, and reduces bundle size by removing duplicate copies of
JSI.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30599215
fbshipit-source-id: abad1398342a5328daa825f3f684e0067cad7a96
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Kudo Chien
Janic Duplessis
Matt Blagden
Dark Knight
John Porto
Nicola Corti
Anandraj Govindan
Andrei Shikov
Andres Suarez
Neil Dhar
Eloy Durán
