Skip to content

V
V8
Switch branch/tag
  1. 20 Apr, 2022 1 commit
  3. 07 Feb, 2022 1 commit
  5. 12 Nov, 2021 1 commit
  7. 30 Sep, 2021 1 commit
  9. 07 Jun, 2021 1 commit
  11. 20 Apr, 2021 1 commit
  13. 08 Apr, 2021 2 commits
  15. 03 Mar, 2021 1 commit
  17. 09 Feb, 2021 1 commit
    • Shu-yu Guo's avatar
      Set is_awaiting on async generators after await's Promise machinery · 8efed0f9
      Shu-yu Guo authored 
      The is_awaiting bit on async generators distinguishes waiting on an
await. When the async generator resumes from an await, the is_awaiting
bit is cleared.

It is possible through overriding Promise#constructor that `await`
throws *after* setting is_awaiting. There is an implicit try-catch
around the body of the async generator such that, usually, caught
exceptions would clear the is_awaiting bit. However, the exception
thrown from a monkeypatched Promise#constructor can be caught by script,
and thus never clear the is_awaiting bit.

This CL sets the is_awaiting bit *after* `await` completes, with the
exception of the return resumption. It is not possible to have the
exception thrown by the await in the return resumption be caught by
script.

Bug: chromium:1171667
Change-Id: I0b615617a5c949f03350ab0f06c42920d43b5488
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659508Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72593}
      8efed0f9
  19. 01 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored 
      CodeAssembler::Parameter now takes a Type template parameter and
performs a checked cast to it. There is also UncheckedParameter which
returns a TNode but doesn't check the cast. The original Parameter
method is still there as UntypedParameter.

Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
cast is performed inside Parameter. Since Parameter is not a macro,
this means it cannot see the original expression or its file name and
line number. So the error messages are vaguely useful, Parameter<T>()
takes a SourceLocation parameter which with a default value of
SourceLocation::Current(), which at least gives us the file name and
line number for the error message.

Bug: v8:6949, v8:10933
Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
  21. 06 May, 2020 1 commit
  23. 17 Feb, 2020 1 commit
  25. 29 Jan, 2020 1 commit
  27. 07 Jan, 2020 1 commit
  29. 09 Oct, 2019 1 commit
  31. 01 Oct, 2019 1 commit
  33. 17 Sep, 2019 1 commit
  35. 16 Sep, 2019 1 commit
  37. 04 Sep, 2019 1 commit
  39. 27 Aug, 2019 1 commit
  41. 23 Aug, 2019 1 commit
  43. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored 
      This replaces all typedefs that define types and not functions by the
equivalent "using" declaration.

This was done mostly automatically using this command:
ag -l '\btypedef\b' src test | xargs -L1 \
     perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'

Patchset 2 then adds some manual changes for typedefs for pointer types,
where the regular expression did not match.

R=mstarzinger@chromium.org
TBR=yangguo@chromium.org, jarin@chromium.org

Bug: v8:9183
Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  45. 22 May, 2019 1 commit
  47. 21 May, 2019 1 commit
  49. 23 Nov, 2018 1 commit
  51. 24 Oct, 2018 1 commit
    • Caitlin Potter's avatar
      [async-await] remove CSA_SLOW_ASSERT in AsyncGeneratorResolve · 9867aa3f
      Caitlin Potter authored 
      The assertion was intended to verify that the function is only called
at appropriate times (at a point when it was called both by by other builtins, and by desugarings added in the parser and during bytecode generation) --- However, it didn't account for the case where
the wrapper Promise is resolved with another JSPromise with a
non-callable "then" method. (Step 12 of
https://tc39.github.io/ecma262/#sec-promise-resolve-functions):

"If IsCallable(thenAction) is false, then
    Return FulfillPromise(promise, resolution)."

It would be observable to verify this behaviour by loading the "then"
value and asserting that it's non-callable, so instead the CSA_ASSERT
is just removed and replaced with a comment explaining the appropriate
use of the function.

BUG=chromium:897436, v8:5855
R=bmeurer@chromium.org

Change-Id: Ib4b11abfe3339409b57ccfda9c3f75a34e0db532
Reviewed-on: https://chromium-review.googlesource.com/c/1296909
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56916}
      9867aa3f
  53. 11 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Introduce dedicated JSAsyncFunctionObject. · a63987a4
      Benedikt Meurer authored 
      This JSAsyncFunctionObject represents the implicit generator object
inside of async functions, and also holds the outer promise for the
async functions. This in turn allows us to get rid of the .promise
in the Parser / BytecodeGenerator completely, and will make it
possible to build zero-cost async stack traces independent of the
concrete synchronous part of the stack frame (which currently breaks
in Node.js).

In the bytecode all the async function operations now take this new
JSAsyncFunctionObject instead of passing both the .generator_object
and the .promise, which further simplifies and shrinks the bytecode.
It also reduces the size of async function frames, potentially making
the suspend/resume cheaper.

This also changes `await` to use intrinsics instead of calling to
special JSFunctions on the native context, and thus reduces the size of
the native contexts.

Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
to TurboFan.

Bug: v8:7253, v8:7522
Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1273049
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56554}
      a63987a4
  55. 29 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Unify handling of await closure contexts. · 9e99297e
      Benedikt Meurer authored 
      Change the way that the (internal) await closures store the link to the
generator object by introducing a dedicated AwaitContext, which stores
the generator object into the extension slot (instead of misusing a
regular FunctionContext here). Also unify the allocation+initialization
of these contexts in the await-related builtins (both for async functions
and generators).

The rationale behind this is that for (zero-cost) async stack traces, we
will need to dig into these contexts and we can do better checking with
a dedicated instance type there. As an additional benefit, we save one
word per await context, since we just use (the otherwise unused) extension
slot to remember the generator object. As yet another benefit we will
never accidentally use any of these contexts in the regular scope chain
lookups, meaning we can also catch bugs there. And last but not least
the objects printing machinery understands these contexts now and can
even print the generator object for AwaitContexts for short printing,
which is really valuable for debugging.

Tbr: ulan@chromium.org
Bug: v8:7253, v8:7522, v8:8015
Change-Id: I86955f5701e694e8a10b91ebe5f52705aa90968d
Reviewed-on: https://chromium-review.googlesource.com/1249491Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56301}
      9e99297e
  57. 20 Sep, 2018 1 commit
  59. 20 Jul, 2018 1 commit
  61. 10 Jul, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-generators] Add fast-path to skip "then" lookup in AsyncGeneratorResolve. · cf080aeb
      Benedikt Meurer authored 
      This extends the Promise#then protector to also guard the intrinsic
%ObjectPrototype%, making it usable for fast-path logic in the
AsyncGeneratorResolve operation, where we can skip the "then" lookup
on the iteratorResult in that case. We also add a corresponding fast-
path to the ResolvePromise builtin itself, which avoids the second
"then" lookup on the async iterator side.

This reduces execution time of the fibonacci-async-es2017-native test
from 298.16ms to 280.55ms, which corresponds to an improvement of ~6%
in this case.

This is a rebased reland of

  https://chromium-review.googlesource.com/967203

which landed earlier, but had to be reverted as part of the mega-revert
that was necessary to fix the async_hooks breakage in Node 10.

Bug: v8:7253
Change-Id: Id9dd1ddc4a8285d64e92cd2030f3168a12e4b509
Reviewed-on: https://chromium-review.googlesource.com/1130523
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54352}
      cf080aeb
  63. 18 Jun, 2018 1 commit
  65. 17 May, 2018 1 commit
  67. 14 May, 2018 1 commit
  69. 27 Mar, 2018 1 commit
  71. 19 Mar, 2018 2 commits
  73. 20 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Turn await closures into intrinsics. · d97bb317
      Benedikt Meurer authored 
      There's no need to have the AsyncFunctionAwait/AsyncGeneratorAwait
operations as separate closures that are called via JavaScript calling
convention, but instead we can just have them as intrinsics (with the
goal to eventually turn them into IC stubs).

Drive-by-fix: Tail call to the ResumeGenerator builtin when resuming
an async function. The earlier restrictions no only apply with the new
machinery.

Bug: v8:7253
Change-Id: I0c4d04dae15b4211158fc07151adafda69d4faec
Reviewed-on: https://chromium-review.googlesource.com/924703Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51382}
      d97bb317
  75. 19 Feb, 2018 1 commit