You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 44634ed
Browse filesBrowse the repository at this point in the historyBrowse files
build: compress V8 pointers in the lite flavor (#6)
lite now configures V8 with --experimental-enable-pointer-compression on
both targets, so tagged pointers become 32-bit offsets from a
per-isolate 4GB cage instead of full 64-bit addresses. The saving lands
on the JS heap rather than on the binary, which is the budget that
decides whether a mobile process stays resident.
An addon that includes V8's headers directly has to be compiled with the
matching V8_COMPRESS_POINTERS / V8_31BIT_SMIS_ON_64BIT_ARCH defines.
N-API addons — the ABI libnode exports, and what the crc-native gate
builds — are unaffected. full stays the upstream-standard binary every
consumer gets by default; lite is the opt-in one whose consumers are
trading compatibility for footprint.
Android gates the flag on arm64/x64. Upstream's common.gypi already
force-disables pointer compression for `target_arch in "arm ia32 mips
mipsel"`, so an ungated flag would build the same uncompressed
armeabi-v7a library — but that guard zeroes the gyp variable, not the
copy configure wrote into config.gypi, so the 32-bit build would ship a
process.config claiming compression it doesn't have. tools/test.py
derives its $pointer_compression status variable from exactly that, and
two parallel tests branch on it. iOS builds arm64 slices only, so it
needs no gate.
Both CI libnode cache keys already hash the file that changed
(android_configure.py, tools/ios_framework_prepare.sh), so neither
flavor can restore a pre-compression binary.
docs/BUILDING.md and the native-modules FAQ entry carry the ABI
consequence; expected-tree.txt moves with the patch.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/FAQ.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -132,6 +132,18 @@ plugins expose an app-data-dir call that does this for you.
132
132
133
133
Node native modules, which contain native code, are able to run on nodejs-mobile, as long as they can be cross-compiled for the target platform / CPU. The cross-compiling feature is integrated into the plugins and instructions can be found in the [nodejs-mobile-cordova](https://github.com/nodejs-mobile/nodejs-mobile-cordova#native-modules) or in the [nodejs-mobile-react-native](https://github.com/nodejs-mobile/nodejs-mobile-react-native#native-modules) README, but only Linux and MacOS development machines are currently supported. Modules that contain custom build steps and platform specific code may need workarounds/changes to get them to work. We've created a github repository so that the workarounds/changes can be discussed and shared: https://github.com/nodejs-mobile/nodejs-mobile-module-compat
134
134
135
+
One caveat if you ship the **lite** flavor: it is built with V8 pointer
136
+
compression, which changes the V8 ABI (see ["Pointer compression" in
137
+
BUILDING.md](./BUILDING.md#pointer-compression-lite-only) on the recipe
138
+
branch). Modules written against **N-API** — the ABI `libnode` exports, and
139
+
what most maintained modules use — are unaffected. A module that includes V8's
140
+
headers directly (`v8.h`, NAN) has to be compiled with the same defines the
141
+
library was: the shipped `include/node` headers carry no `config.gypi`, so add
142
+
`-DV8_COMPRESS_POINTERS -DV8_31BIT_SMIS_ON_64BIT_ARCH` to that module's build
143
+
for the lite flavor (and nothing extra for full). Compiled without them and
144
+
loaded into lite, it reads object fields at the wrong offsets. The `full`
145
+
flavor keeps the upstream-standard ABI.
146
+
135
147
## How can I improve Node.js load times?
136
148
137
149
Applications that contain a large number of files in the Node.js project can have their load times decreased by reducing the number of files. While installing npm modules, these can be installed with the `--production` flag, so that modules that are used for development only are not included in your project, e.g.: `npm install --production <module_name>`. Using tools that merge all nodejs project files into a bundle, such as [`noderify`](https://www.npmjs.com/package/noderify) or [`esbuild`](https://esbuild.github.io/) and using the bundle instead has been observed to improve load times in most situations.
0 commit comments