<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/node-new.git/src/node_code_cache_stub.cc, branch crypto_set_integer_macro</title>
<subtitle>github.com: nodejs/node.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/node-new.git/'/>
<entry>
<title>src: perform integrity checks on built-in code cache</title>
<updated>2018-08-17T21:21:52+00:00</updated>
<author>
<name>Joyee Cheung</name>
<email>joyeec9h3@gmail.com</email>
</author>
<published>2018-08-06T15:27:03+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/node-new.git/commit/?id=7cbbb27c0721ced7b74fc39033c8485b8d2ad864'/>
<id>7cbbb27c0721ced7b74fc39033c8485b8d2ad864</id>
<content type='text'>
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 &lt;anna@addaleax.net&gt;
Reviewed-By: Tiancheng "Timothy" Gu &lt;timothygu99@gmail.com&gt;
Reviewed-By: James M Snell &lt;jasnell@gmail.com&gt;
Reviewed-By: Gus Caplan &lt;me@gus.host&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;anna@addaleax.net&gt;
Reviewed-By: Tiancheng "Timothy" Gu &lt;timothygu99@gmail.com&gt;
Reviewed-By: James M Snell &lt;jasnell@gmail.com&gt;
Reviewed-By: Gus Caplan &lt;me@gus.host&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>build: speed up startup with V8 code cache</title>
<updated>2018-06-27T13:11:31+00:00</updated>
<author>
<name>Joyee Cheung</name>
<email>joyeec9h3@gmail.com</email>
</author>
<published>2018-06-18T17:02:57+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/node-new.git/commit/?id=4750ce26f2e6079b5fee92bdee5356c279171d22'/>
<id>4750ce26f2e6079b5fee92bdee5356c279171d22</id>
<content type='text'>
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 &lt;john.david.dalton@gmail.com&gt;
Reviewed-By: Anna Henningsen &lt;anna@addaleax.net&gt;
Reviewed-By: Gus Caplan &lt;me@gus.host&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;john.david.dalton@gmail.com&gt;
Reviewed-By: Anna Henningsen &lt;anna@addaleax.net&gt;
Reviewed-By: Gus Caplan &lt;me@gus.host&gt;
</pre>
</div>
</content>
</entry>
</feed>
