Skip to content

V
V8
Switch branch/tag
  1. 01 Feb, 2022 1 commit
  3. 31 Jan, 2022 1 commit
  5. 27 Jan, 2022 1 commit
  7. 17 Jan, 2022 1 commit
    • Victor Gomes's avatar
      Reland "[runtime] Adds LocalNameIterator" · 4ebc9b7b
      Victor Gomes authored 
      This is a reland of f605d778

Adds a GC safe (using handles) and unsafe versions of the iterator.

V8HeapExplorer needs an unsafe one, since it does not allow the
creation of handles.

Original change's description:
> [runtime] Adds LocalNameIterator
>
> ScopeInfo will contain either inlined (array) local names or
> a hash table (names => index) containing the local names.
>
> We abstract iteration with LocalNameIterator and remove
> ContextLocalName since accessing a local name by index in
> the hash table would be expensive.
>
> This CL only implements the iterator for the array.
>
> Bug: v8:12315
> Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78623}

Bug: v8:12315
Change-Id: I6288a08b9c342cd3a9cabcb621c40bb44c08c9c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394706Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78653}
      4ebc9b7b
  9. 14 Jan, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "[runtime] Adds LocalNameIterator" · 1e42a27f
      Leszek Swirski authored 
      This reverts commit f605d778.

Reason for revert: Segfaults: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36908/overview

Original change's description:
> [runtime] Adds LocalNameIterator
>
> ScopeInfo will contain either inlined (array) local names or
> a hash table (names => index) containing the local names.
>
> We abstract iteration with LocalNameIterator and remove
> ContextLocalName since accessing a local name by index in
> the hash table would be expensive.
>
> This CL only implements the iterator for the array.
>
> Bug: v8:12315
> Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78623}

Bug: v8:12315
Change-Id: Ibabe231f4357a3dd02d24b89847d579b83867a1a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386385
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78625}
      1e42a27f
    • Victor Gomes's avatar
      [runtime] Adds LocalNameIterator · f605d778
      Victor Gomes authored 
      ScopeInfo will contain either inlined (array) local names or
a hash table (names => index) containing the local names.

We abstract iteration with LocalNameIterator and remove
ContextLocalName since accessing a local name by index in
the hash table would be expensive.

This CL only implements the iterator for the array.

Bug: v8:12315
Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78623}
      f605d778
  11. 13 Jan, 2022 2 commits
    • Lei Zhang's avatar
      Remove many superfluous STL includes in headers. · 87cf0bdd
      Lei Zhang authored 
      Use grep to check for obviously unneeded includes. e.g. headers that
include <vector> but does not contain "std::vector".

Change-Id: I43a9e9f01e072fd495918d28ca4cdad5cfa0294c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354400Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78613}
      87cf0bdd
    • Benedikt Meurer's avatar
      [debug] Simplify async function instrumentation. · 41f0c0ba
      Benedikt Meurer authored 
      This unifies and simplifies the way we instrument async functions for
the purpose of async stack traces and async stepping. It does so while
retaining the observable behavior on the inspector level (for now).

Previously we'd mark the implicit promise of the async function object
with the async task ID, and whenever we awaited, we'd copy the async
task ID to the throwaway promise that is created by the `await`. This
however made things unnecessarily interesting in the following regards:

1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
`AsyncFunctionFinished` events, coming from the throwaway promises,
while the implicit promise is "done". This is especially confusing
with rejection propagation and requires very complex stepping logic
for async functions (after this CL it'll be possible to unify and
simplify the stepping logic).
2. We have to thread through the "can suspend" information from the
Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
to the async function instrumentation to decide whether to cancel the
pending task when the async function finishes.

This CL changes the instrumentation to only happen (non recurringly) for
the throwaway promises allocated upon `await`. This solves both problems
mentioned above, and works because upon the first `await` the stack
captured for the throwaway promise will include the synchronous part as
expected, while upon later `await`s the synchronous part will be empty
and the asynchronous part will be the stack captured for the previous
throwaway promise (and the V8Debugger automatically short circuits
stacks with empty synchronous part).

Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78599}
      41f0c0ba
  13. 12 Jan, 2022 1 commit
    • Simon Zünd's avatar
      [debug] Add new 'CreateMessageFromException' function · c0682832
      Simon Zünd authored 
      CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).

The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. This means we can't reuse Isolate::CreateMessage as
the JS stack at call time is unrelated to the time when an Error
object was thrown.

To re-use some of the code, this CL introduces a new
"CreateMessageFromException" method that is only available from the
debugging interface (not public V8 API!). The new method works
similar to Isolate::CreateMessage, but:
  1) Does not look at the current JS stack, neither for a fresh
     stack trace nor for location information.
  2) Only uses the "detailed" stack trace for location info.
     This is because the "simple" stack trace could have already
     been serialized by accessing Error#stack.

Bug: chromium:1278650
Doc: https://bit.ly/runtime-get-exception-details
Change-Id: I0144516001c71786b9f76ae4dec4442fa1468c5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337257Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78586}
      c0682832
  15. 11 Jan, 2022 1 commit
  17. 05 Jan, 2022 1 commit
  19. 29 Dec, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Correct location for inline scripts with sourceURL. · a81e8d16
      Benedikt Meurer authored 
      Previously the `Debugger.CallFrame`s in `Debugger.paused` events would
report locations relative to the surrounding document in case of inline
scripts with `//@ sourceURL` annotations (while `Runtime.CallFrame` was
already fixed previously as part of crrev.com/c/3069289). With this CL
the locations in `Debugger.CallFrame` are also appropriately adjusted.

Drive-by-fix: Several inspector tests were (incorrectly) relying on this
wrong treatment, and were also unnecessarily using //# sourceURL
annotations. So part of this CL also addresses that problem and makes
the tests more robust, using addInlineScript() helper.

Fixed: chromium:1283049
Bug: chromium:1183990, chromium:578269
Change-Id: I6e3b215d951c3453c0a9cfc9bccf3dc3d5e92fd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359619
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78450}
      a81e8d16
  21. 16 Dec, 2021 1 commit
  23. 15 Dec, 2021 1 commit
  25. 14 Dec, 2021 2 commits
  27. 13 Dec, 2021 1 commit
  29. 08 Dec, 2021 2 commits
    • Leszek Swirski's avatar
      [compiler] Introduce ReusableUnoptimizedCompileState · b3e1eb0c
      Leszek Swirski authored 
      Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
which stores a couple of pointers and most importantly the Zone and
AstValueFactory of the parse. This allows the Zone and AstValueFactory
to be reused across multiple parses, rather than re-initialising
per-Parse.

With this, we can amend the LazyCompileDispatcher to initialise one
LocalIsolate, Zone and AstValueFactory per background thread loop,
rather than one per compile task, which allows us to reduce per-task
costs and re-use the AstValueFactory's string table and previous String
internalizations.

Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78289}
      b3e1eb0c
    • Benedikt Meurer's avatar
      [inspector] Consistent frame function name in V8 Inspector and API. · 54584461
      Benedikt Meurer authored 
      On the way to a cheaper and more scalable stack frame representation
for the inspector (crbug/1258599), this removes the need to expose
both what was called "function name" and what was called "function
debug name" on a v8::StackFrame instance.

The reason to having a distinction between that the V8 API exposes
and what the inspector exposes as frame function name is that after
the initial refactoring around v8::internal::StackFrameInfo, some
wasm cctests would still dig into the implementation details and
insist on seeing the "function name" rather than the "function
debug name". This CL now addresses that detail in the wasm cctests
and going forward unifies the function names used by the inspector
and the V8 API (which is not only needed for internal consistency
and reduced storage requirements in the future, but also because
Blink for example uses v8 API and v8_inspector API interchangeably
and assumes that they agree, even though at this point Blink
luckily wasn't paying attention to the function name):

- The so-called "detailed stack trace", which is produced for the
  inspector and exposed by the v8 API, always yields the "function
  debug name" (which for example in case of wasm will be a WAT
  compatible name),
- while the so-called "simple stack trace", which is what is used
  to implement the CallSite API and underlies Error.stack continues
  to stick to the "function name" which in case of wasm is not
  WAT compatible).

Bug: chromium:1258599
Change-Id: Ib15d038f3ec893703d0f7b03f6e7573a38e82b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312274Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78283}
      54584461
  31. 07 Dec, 2021 1 commit
  33. 03 Dec, 2021 1 commit
  35. 02 Dec, 2021 2 commits
  37. 30 Nov, 2021 2 commits
  39. 29 Nov, 2021 1 commit
  41. 24 Nov, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm] Internal representation for function references · f60132e9
      Manos Koukoutos authored 
      Design doc: bit.ly/3jEVgzz

We separate the internal representation of function references in Wasm
from their JSFunction-based (external) representation. This improves
performance of call_ref by requiring less indirections to load the
context and call target from a function reference. In the boundary
between wasm and JS/the C API, we add transformations between the two
representations.

Detailed changes:
- Introduce WasmInternalFunction, containing fields required by
  call_ref, as well as a reference to the corresponding
  WasmExternalFunction. Add a reference to the WasmInternalFunction in
  WasmFunctionData. The {WasmInternalFunction::FromExternal} helper
  extracts the internal out of an external function.
- Change {WasmInstanceObject::external_functions()} to internal
  functions.
- Change wasm function tables to contain internal functions.
- Change the following code to use internal functions:
  - call_ref in liftoff and Turbofan
  - function type checks in liftoff and Turbofan
  - CallRefIC and GenericJSToWasmWrapper builtins
  - {InitExprInterface::RefFunc}
  - module-compiler.cc in {ProcessTypeFeedback}
  - In module-instantiate.cc, in function-rtt creation.
- Add transformations between internal and external functions in:
  - WasmWrapperGraphBuilder::{ToJS, BuildUnpackObjectWrapper, FromJS,
    BuildJSToJSWrapper}.
  - debug-wasm-objects.cc in {FunctionProxy::Get},
    {WasmValueObject::New} and {AddWasmTableObjectInternalProperties}.
  - runtime-wasm.cc in ReplaceWrapper
  - the C and JS APIs
  - module-instantiate.cc, in import and export processing, as well as
    {InitializeIndirectFunctionTables}
  - WasmTableObject::{IsValidElement, SetFunctionTableEntry}
  - {WasmGlobalObject::SetFuncRef}
- Simplify body descriptors of WasmExternalFunction variants.
- Adjust tests.

Bug: v8:11510

Change-Id: I8377f46f55c3771391ae1c5c8201a83854ee7878
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277878Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78068}
      f60132e9
  43. 18 Nov, 2021 1 commit
  45. 16 Nov, 2021 1 commit
  47. 12 Nov, 2021 1 commit
  49. 10 Nov, 2021 1 commit
  51. 09 Nov, 2021 1 commit
  53. 08 Nov, 2021 1 commit
  55. 03 Nov, 2021 1 commit
  57. 02 Nov, 2021 1 commit
    • Yang Guo's avatar
      Allow name collision when materializing scope object · 5395045f
      Yang Guo authored 
      When materializing a scope object, we previously assumed that we will
not have any name collisions. This is not correct e.g. when eval
introduces an aliased local variable.

This CL resolves this wrong assumption. The test case should not crash.
It however fails as there is a bug in how debug-evaluate should resolve
variables defined in eval.

R=verwaest@chromium.org

Fixed: chromium:1240962
Bug: chromium:1264852
Change-Id: I0e41e7905589735e25eff221376d09997ea99117
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250911
Auto-Submit: Yang Guo <yangguo@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77649}
      5395045f
  59. 28 Oct, 2021 2 commits
  61. 27 Oct, 2021 1 commit
    • Camillo Bruni's avatar
      [api] Deprecate v8::ScriptCompiler::CompileFunctionInContext · 78387ca7
      Camillo Bruni authored 
      - Introduce v8::ScriptCompiler::CompileFunction
- Deprecate v8::ScriptCompiler::CompileFunctionInContext
- Add v8::Function::GetUnboundScript
- Add v8::Script::GetResourceName

The ScriptOrModule out-parameter is only used by NodeJS since we don't
allow arbitrary objects has host-defined options and they need a way to
keep the options alive.

This CL deprecates the out-parameter and adds helper methods to
address the most common use-cases.

The final fix still requires more fundamental changes on how host-defined
options are handled.

Bug: chromium:1244145
Change-Id: Id29de53521ad626c41391b8300146ee37a1b8a51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245117Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77564}
      78387ca7
  63. 25 Oct, 2021 1 commit
  65. 21 Oct, 2021 1 commit