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 5ba8aab
Browse filesBrowse the repository at this point in the historyBrowse files
Reland "[parser] Create debug magic comment values as source substrings"
This is a reland of commit 8dcf14f
Changes since the original:
The original made every value with at least SlicedString::kMinLength
characters a SlicedString of the source, including usual source URLs
like //# sourceURL=inside-direct-eval.js. Heap snapshots name sliced
strings "(sliced string)" instead of by their contents, so DevTools'
heap snapshot ContextAnalyzer, which reads the name of the script's
source_url node, showed "(sliced string)" instead of the source URL.
The source URL is now always a sequential copy of its value, as
before the original (which internalized it), since it is used as the
script name (stack traces, profiles, heap snapshots). The debug ID is
also copied, since it is short. Only the sourceMappingURL value is a
substring of the source, which covers the case the original was about
(huge inline source maps). A huge sourceURL or debugId value is copied
onto the heap as before the original.
Added a regression test that a source URL longer than
SlicedString::kMinLength is sequential (script, streaming and direct
eval) and that heap snapshots name the source_url node by it, and
updated the existing tests accordingly.
Original change's description:
> [parser] Create debug magic comment values as source substrings
>
> The values of the //# sourceURL, sourceMappingURL and debugId magic
> comments were copied into LiteralBuffers while scanning and then
> internalized. An inline source map (sourceMappingURL=data:...) can be
> tens of MiB, so this allocated a string of that size on the heap in a
> non-throwing allocation, e.g. aborting a Node.js worker with a small
> old-generation limit even though the (external) source fits.
>
> The scanner now only records the source locations of these values, and
> the values are created as substrings of the script source:
> - On the main thread, when parsing finishes.
> - For background and streaming compiles, where the source is not
> available while parsing, the locations are kept in the
> BackgroundCompileTask and the substrings are created in
> FinalizeScript after the source is set. Locations outside of the
> source provided by the embedder are ignored.
>
> The semantics are unchanged: the last comment wins, trailing garbage or
> an empty value removes the value, and a source map URL provided through
> the API takes precedence.
>
> Since these values are now usually SlicedStrings of the script source,
> the code serializer serializes all sliced strings as sequential
> strings (one-byte if their contents are, even if their parent is
> two-byte). The script source is an attached object, and off-thread
> deserialization attaches a placeholder for it, so a serialized slice
> of it would not be valid.
>
> Consuming a code cache still materializes these values as sequential
> strings, e.g. on Node.js's NODE_COMPILE_CACHE path, so a huge cached
> value can still be large on the heap there. Keeping them as substrings
> of the source when deserializing requires a code cache format change
> and is left for a follow-up.
>
> This also removes the LiteralBuffer copies of the values.
>
> [email protected], [email protected]
>
> Bug: 566467883
> Refs: nodejs/node#64155
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8472768
> Reviewed-by: Leszek Swirski <[email protected]>
> Reviewed-by: Patrick Thier <[email protected]>
> Cr-Commit-Position: refs/heads/main@{#110612}
[email protected], [email protected], [email protected]
Bug: 566467883
Change-Id: I76eec1fdaf71526afdd881d0d4a2b117c32d3ba8
Refs: nodejs/node#64155
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8579167
Reviewed-by: Patrick Thier <[email protected]>
Commit-Queue: Patrick Thier <[email protected]>
Reviewed-by: Toon Verwaest <[email protected]>
Cr-Commit-Position: refs/heads/main@{#111132}
0 commit comments