This brings DEP0084 to End-of-Life. It is unlikely that this
has received much public usage in the first place, so removing
should be okay.
PR-URL: https://github.com/nodejs/node/pull/25138
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
In preparation of sharing code cache among different threads -
we simply rely on v8 to reject invalid cache, since there isn't
any serious consequence when the cache is invalid anyway.
PR-URL: https://github.com/nodejs/node/pull/24950
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Instead of treating config.gypi as a JavaScript file, specialize
the processing in js2c and make the serialized result a real JSON
string (with 'true' and 'false' converted to boolean values) so
we don't have to use a custom deserializer during bootstrap.
In addition, store the JSON string separately in NativeModuleLoader,
and keep it separate from the map of the builtin source code, so
we don't have to put it onto `NativeModule._source` and delete it
later, though we still preserve it in `process.binding('natives')`,
which we don't use anymore.
This patch also makes the map of builtin source code and the
config.gypi string available through side-effect-free getters
in C++.
PR-URL: https://github.com/nodejs/node/pull/24816
Reviewed-By: Gus Caplan <me@gus.host>
Instead of putting the source code and the cache in v8::Objects,
put them in per-process std::maps. This has the following benefits:
- It's slightly lighter in weight compared to storing things on the
v8 heap. Also it may be slightly faster since the preivous v8::Object
is already in dictionary mode - though the difference is very small
given the number of native modules is limited.
- The source and code cache generation templates are now much simpler
since they just initialize static arrays and manipulate STL
constructs.
- The static native module data can be accessed independently of any
Environment or Isolate, and it's easy to look them up from the
C++'s side.
- It's now impossible to mutate the source code used to compile
native modules from the JS land since it's completely separate
from the v8 heap. We can still get the constant strings from
process.binding('natives') but that's all.
A few drive-by fixes:
- Remove DecorateErrorStack in LookupAndCompile - We don't need to
capture the exception to decorate when we encounter
errors during native module compilation, as those errors should be
syntax errors and v8 is able to decorate them well. We use
CompileFunctionInContext so there is no need to worry about
wrappers either.
- The code cache could be rejected when node is started with v8 flags.
Instead of aborting in that case, simply keep a record in the
native_module_without_cache set.
- Refactor js2c.py a bit, reduce code duplication and inline Render()
to make the one-byte/two-byte special treatment easier to read.
PR-URL: https://github.com/nodejs/node/pull/24384
Fixes: https://github.com/Remove
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently V8 only checks that the length of the source code is the
same as the code used to generate the hash, so we add an additional
check here:
1. During compile time, when generating node_javascript.cc and
node_code_cache.cc, we compute and include the hash of the
(unwrapped) JavaScript source in both.
2. At runtime, we check that the hash of the code being compiled
and the hash of the code used to generate the cache
(inside the wrapper) is the same.
This is based on the assumptions:
1. `internalBinding('code_cache_hash')` must be in sync with
`internalBinding('code_cache')` (same C++ file)
2. `internalBinding('natives_hash')` must be in sync with
`process.binding('natives')` (same C++ file)
3. If `internalBinding('natives_hash')` is in sync with
`internalBinding('natives_hash')`, then the (unwrapped)
code used to generate `internalBinding('code_cache')`
should be in sync with the (unwrapped) code in
`process.binding('natives')`
There will be, however, false positives if the wrapper used
to generate the cache is different from the one used at run time,
and the length of the wrapper somehow stays the same.
But that should be rare and can be eased once we make the
two bootstrappers cached and checked as well.
PR-URL: https://github.com/nodejs/node/pull/22152
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Do not expose symbols like `node::internal_process_next_tick_value`,
`node::internal_process_next_tick_key` in the created `node` binary
by wrapping them in an anonymous namespace.
PR-URL: https://github.com/nodejs/node/pull/20634
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
- Moves the creation of `process.binding()`, `process._linkedBinding()`
`internalBinding()` and `NativeModule` into a separate file
`lib/internal/bootstrap_loaders.js`, and documents them there.
This file will be compiled and run before `bootstrap_node.js`, which
means we now bootstrap the internal module & binding system before
actually bootstrapping Node.js.
- Rename the special ID that can be used to require `NativeModule`
as `internal/bootstrap_loaders` since it is setup there. Also put
`internalBinding` in the object exported by `NativeModule.require`
instead of putting it inside the `NativeModule.wrapper`
- Use the original `getBinding()` to get the source code of native
modules instead of getting it from `process.binding('native')`
so that users cannot fake native modules by modifying the binding
object.
- Names the bootstrapping functions so their names show up
in the stack trace.
PR-URL: https://github.com/nodejs/node/pull/19112
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Detect it when source files in lib/ are not ASCII. Decode them as UTF-8
and store them as UTF-16 in the binary so they can be used as external
string resources without non-ASCII characters getting mangled.
Fixes: https://github.com/nodejs/node/issues/10673
PR-URL: https://github.com/nodejs/node/pull/11129
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Use zero-copy external string resources for storing the built-in JS
source code. Saves a few hundred kilobyte of memory and consistently
speeds up `benchmark/misc/startup.js` by 2.5%.
Everything old is new again! Commit 74954ce ("Add string class that
uses ExternalAsciiStringResource.") from 2011 did the same thing but
I removed that in 2013 in commit 34b0a36 ("src: don't use NewExternal()
with unaligned strings") because of a limitation in the V8 API.
V8 no longer requires that strings are aligned if they are one-byte
strings so it should be safe to re-enable external strings again.
PR-URL: https://github.com/nodejs/node/pull/5458
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Robert Jefe Lindstaedt <robert.lindstaedt@gmail.com>
As the minifier logic is not used at all, this patch removes the code
necessary for it.
PR-URL: https://github.com/nodejs/node/pull/6636
Reviewed-By: Jackson Tian <shvyo1987@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This change cleans up outstanding comments on #3032. It improves error
handling when no isolate file is provided and adds the --prof-process
flag to the node binary which executes the tick processor on the
provided isolate file.
PR-URL: https://github.com/nodejs/node/pull/4021
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Evan Lucas <evanlucas@me.com>
These are the core changes that allow AIX to compile. There
are still some test failures as there are some patches needed for
libuv and npm that we'll need to contribute through those
communities but this set allows node to be built on AIX and
pass most of the core tests
The change in js2c is because AIX does not support $ in
identifier names. See the discussion/agreement in
https://github.com/nodejs/node/issues/2272
PR-URL: https://github.com/nodejs/node/pull/2364
Reviewed-By: Ben Noordhuis <ben@strongloop.com>
Reviewed-By: Rod Vagg <r@va.gg>
Fix a regression that was introduced in commit 2db758c ("iojs: introduce
internal modules") where the computed id for "config.gypi" on Windows
was not "config" but an empty string.
With an empty string, the build succeeds but the binary is unusable:
startup.processConfig() in src/node.js chokes on the missing .config
property.
PR-URL: https://github.com/iojs/io.js/pull/1281
Reviewed-By: Vladimir Kurchatkin <vladimir.kurchatkin@gmail.com>
Internal modules can be used to share private code between
public modules without risk to expose private APIs to the
user.
PR-URL: https://github.com/iojs/io.js/pull/848
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Squashed commit of ca128f7dcd28cbcfba154c8577ed54d4aa71dd02 with
contributions from Mark Constable (markc@renta.net) and Daniel Gröber
(darklord@darkboxed.org).
Instead of installing the files in /usr/lib/node/libraries and loading them
from the file system, the files are built-in to the node executable.
However, they are only compiled on demand.
The reasoning is:
1. Allow for more complex internal javascript. In particular,
process.stdout and process.stdin can be js implemented streams.
2. Ease system installs. Loading from disk each time is unnecessary
overhead. Note that there is no "system" path for modules anymore. Only
$HOME/.node_libraries.
