Update to newer JSC and use Bun's fork #187
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
…nary, but without vectorization (helped by the -O2 inlining), the interpreter hot path might not stay hot in the CPU caches. if using JSC on Android, users probably have a Very Good Reason(tm), but I'm not sure which they care about more: app download size or performance per watt efficiency.
Co-authored-by: Kudo Chien <ckchien@gmail.com>
…warning (to about warnings as errors killing the build unnecessarily), but also disable loop vectorization options until NDK can be bumped. downgrade to c++20 to align with React Native constraints.
…erable on any build machine
…about LTO for the binary bits that end up in the app package itself anyway. gradefully degrade to generic LTO when clang isn't detected on the system. when clang is detected, make sure we use it for generating the ICU host-run codegen
… (pixel 2 and above) for the superior vectorization codegen that's possible
…-class GC collectible, which can cause OOM on a specific synthetic stress test on mobile/wearable devices
…le React Native's lagging toolchain from other downstream users like BabylonNative
…for that matter, use cccache so that incremental updates from upstream bun-sh/webkit don't trigger the 90+ minute (time three, for each NDK) build.
…s lost when rebasing the existing patch stack on the new JSC. efault collator lazy-property is now wrapped in #if ENABLE(INTL) so the no-intl flavor never tries to instantiate ICU machinery it does not ship. BabylonNative needs Inspector APIs to be available, and SharedArrayBuffer is now enabled for efficient communication via N-API native modules. add a small smoketest binary for NDK 28 and NDK 29 validation in Android simulator outside of the React Native-mandated NDK 27. we now have a way to validate runtime effectiveness of all NDK variant compiles within CI.
…so maybe something else is up in the compiler environment now?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
The intent is to deduplicate customized JSC verisons floating around in the ecosystem, and get a newer JSC available to BabylonNative (which uses this repo's npm package).
Why Bun? Bun has made seriializing and caching bytecode, rather than text bundles, commonplace and provided a huge boost to node-like development. We know the value of bytecode bundles in React Native very well: ChakraCore bytecode bundles in 2016 shaved 1 second of time off app launches in React Native Windows, and Hermes bytecode bundles have similar measurable uplift to user experience. Upstream JavaScriptCore has these APIs, but doesn't put them as public -- Bun's fork exposes this plumbing and gives another way we can deploy bytecode bundles via another JS runtime whose performance characteristics may be better for a given workload.