delta/node-new.git/src/node_code_cache_stub.cc, branch sam-github-tsc

src: remove ref to tools/generate_code_cache.js

2020-06-15T04:00:15+00:00

This commit removes the reference to tools/generate_code_cache.js
and replaces it with a note about more information being available
in tools/code_cache/README.md.

PR-URL: https://github.com/nodejs/node/pull/33825
Reviewed-By: Richard Lau 
Reviewed-By: David Carlier

src,test: add full-featured embedder API test

2020-03-21T09:58:23+00:00

PR-URL: https://github.com/nodejs/node/pull/30467
Reviewed-By: James M Snell 
Reviewed-By: Gireesh Punathil

build: improve embedded code-cache detection

2019-04-22T18:48:50+00:00

PR-URL: https://github.com/nodejs/node/pull/27311
Reviewed-By: Joyee Cheung 
Reviewed-By: Richard Lau

src: make a Environment-independent proxy class for NativeModuleLoader

2019-04-13T09:24:51+00:00

This patch splits `NativeModuleLoader` into two parts - a singleton
that only relies on v8 and `node::Mutex` and a proxy class for
the singleton (`NativeModuleEnv`) that provides limited access to
the singleton as well as C++ bindings for the Node.js binary.
`NativeModuleLoader` is then no longer aware of `Environment`.

PR-URL: https://github.com/nodejs/node/pull/27160
Reviewed-By: Anna Henningsen 
Reviewed-By: Richard Lau

src: remove code cache integrity check

2018-12-18T10:02:08+00:00

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

src: use STL containers instead of v8 values for static module data

2018-11-19T17:17:15+00:00

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 
Reviewed-By: Franziska Hinkelmann 
Reviewed-By: Tiancheng "Timothy" Gu 
Reviewed-By: James M Snell

src: compile native modules and their code cache in C++

2018-11-14T18:30:40+00:00

This patch refactors out a part of NativeModule.prototype.compile
(in JS land) into a C++ NativeModule class, this enables a
couple of possibilities:

1. By moving the code to the C++ land, we have more opportunity
  to specialize the compilation process of the native modules
  (e.g. compilation options, code cache) that is orthogonal to
  how user land modules are compiled
2. We can reuse the code to compile bootstrappers and context
  fixers and enable them to be compiled with the code cache later,
  since they are not loaded by NativeModule in the JS land their
  caching must be done in C++.
3. Since there is no need to pass the static data to JS for
  compilation anymore, this enables us to use
  (std::map) in the generated
  node_code_cache.cc and node_javascript.cc later, and scope
  every actual access to the source of native modules to a
  std::map lookup instead of a lookup on a v8::Object in
  dictionary mode.

This patch also refactor the code cache generator and tests
a bit and trace the `withCodeCache` and `withoutCodeCache`
in a Set instead of an Array, and makes sure that all the cachable
builtins are tested.

PR-URL: https://github.com/nodejs/node/pull/24221
Reviewed-By: Refael Ackermann 
Reviewed-By: Anna Henningsen

src: perform integrity checks on built-in code cache

2018-08-17T21:21:52+00:00

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 
Reviewed-By: Tiancheng "Timothy" Gu 
Reviewed-By: James M Snell 
Reviewed-By: Gus Caplan

build: speed up startup with V8 code cache

2018-06-27T13:11:31+00:00

This patch speeds up the startup time and reduce the startup memory
footprint by using V8 code cache when comiling builtin modules.

The current approach is demonstrated in the `with-code-cache`
Makefile target (no corresponding Windows target at the moment).

1. Build the binary normally (`src/node_code_cache_stub.cc` is used),
  by now `internalBinding('code_cache')` is an empty object
2. Run `tools/generate_code_cache.js` with the binary, which generates
  the code caches by reading source code of builtin modules off source
  code exposed by `require('internal/bootstrap/cache').builtinSource`
  and then generate a C++ file containing static char arrays of the
  code cache, using a format similar to `node_javascript.cc`
3. Run `configure` with the `--code-cache-path` option so that
  the newly generated C++ file will be used when compiling the
  new binary. The generated C++ file will put the cache into
  the `internalBinding('code_cache')` object with the module
  ids as keys
4. The new binary tries to read the code cache from
  `internalBinding('code_cache')` and use it to compile
  builtin modules. If the cache is used, it will put the id
  into `require('internal/bootstrap/cache').compiledWithCache`
  for bookkeeping, otherwise the id will be pushed into
  `require('internal/bootstrap/cache').compiledWithoutCache`

This patch also added tests that verify the code cache is
generated and used when compiling builtin modules.

The binary with code cache:

- Is ~1MB bigger than the binary without code cahe
- Consumes ~1MB less memory during start up
- Starts up about 60% faster

PR-URL: https://github.com/nodejs/node/pull/21405
Reviewed-By: John-David Dalton 
Reviewed-By: Anna Henningsen 
Reviewed-By: Gus Caplan