Skip to content

V
V8
Switch branch/tag
  1. 16 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored 
      Add support for internalizing an AstValueFactory using the off-thread
factory. Includes adding ConsString support to OffThreadFactory.

This introduces a Handle union wrapper, which is used in locations that
can store a Handle or an OffThreadHandle. This is used in this patch for
the internalized "string" field of AST strings, and will be able to be
used for other similar fields in other classes (e.g. the ScopeInfo
handle in Scope, object boilerplate descriptor handles, the inferred
name handle on FunctionLiterals, etc.). It has a Factory-templated
getter which returns the appropriate handle for the factory, and a
debug-only tag to make sure the right getter is used at runtime. This
union wrapper currently decomposes implicitly to a Handle if the getter
is not called, to minimise code changes, but this implicit conversion
will likely be removed for clarity.

Bug: chromium:1011762
Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  3. 09 Jan, 2020 1 commit
  5. 08 Jan, 2020 1 commit
  7. 02 Jan, 2020 1 commit
  9. 06 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Reland "Implement top-level await for REPL mode" · f96f9312
      Simon Zünd authored 
      This is a reland of 5bddc0e1

The original CL was speculatively reverted as it was suspected to
cause failures on the non-determinism bot. This was ultimately
confirmed to not be the case, so this CL is safe to reland as-is.

Original change's description:
> Implement top-level await for REPL mode
>
> Design doc: bit.ly/v8-repl-mode
>
> This CL allows the usage of 'await' without wrapping code in an async
> function when using REPL mode in global evaluate. REPL mode evaluate
> is changed to *always* return a Promise. The resolve value of the
> promise is the completion value of the REPL script.
>
> The implementation is based on two existing mechanisms:
>   - Similar to async functions, the content of a REPL script is
>     enclosed in a synthetic 'try' block. Any thrown error
>     is used to reject the Promise of the REPL script.
>
>   - The content of the synthetic 'try' block is also re-written the
>     same way a normal script is. This is, artificial assignments to
>     a ".result" variable are inserted to simulate a completion
>     value. The difference for REPL scripts is, that ".result" is
>     used to resolve the Promise of the REPL script.
>
>   - ".result" is not returned directly but wrapped in an object
>     literal: "{ .repl_result: .result}". This is done to prevent
>     resolved promises from being chained and resolved prematurely:
>
>     > Promse.resolve(42);
>
>     should evaluate to a promise, not 42.
>
> Bug: chromium:1021921
> Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65273}

TBR: yangguo@chromium.org,verwaest@chromium.org
Bug: chromium:1021921
Change-Id: I95c5dc17593161009a533188f91b4cd67234c32f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954388Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65360}
      f96f9312
  11. 04 Dec, 2019 1 commit
    • Maya Lekova's avatar
      Revert "Implement top-level await for REPL mode" · 99005f33
      Maya Lekova authored 
      This reverts commit 5bddc0e1.

Reason for revert: Possible culprit for https://bugs.chromium.org/p/chromium/issues/detail?id=1029863

Original change's description:
> Implement top-level await for REPL mode
> 
> Design doc: bit.ly/v8-repl-mode
> 
> This CL allows the usage of 'await' without wrapping code in an async
> function when using REPL mode in global evaluate. REPL mode evaluate
> is changed to *always* return a Promise. The resolve value of the
> promise is the completion value of the REPL script.
> 
> The implementation is based on two existing mechanisms:
>   - Similar to async functions, the content of a REPL script is
>     enclosed in a synthetic 'try' block. Any thrown error
>     is used to reject the Promise of the REPL script.
> 
>   - The content of the synthetic 'try' block is also re-written the
>     same way a normal script is. This is, artificial assignments to
>     a ".result" variable are inserted to simulate a completion
>     value. The difference for REPL scripts is, that ".result" is
>     used to resolve the Promise of the REPL script.
> 
>   - ".result" is not returned directly but wrapped in an object
>     literal: "{ .repl_result: .result}". This is done to prevent
>     resolved promises from being chained and resolved prematurely:
> 
>     > Promse.resolve(42);
> 
>     should evaluate to a promise, not 42.
> 
> Bug: chromium:1021921
> Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65273}

TBR=yangguo@chromium.org,leszeks@chromium.org,verwaest@chromium.org,szuend@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:1021921
Change-Id: I9eaea584e2e09f3dffcbbca3d75a3c9bcb0a1adf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948719Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65333}
      99005f33
  13. 02 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Implement top-level await for REPL mode · 5bddc0e1
      Simon Zünd authored 
      Design doc: bit.ly/v8-repl-mode

This CL allows the usage of 'await' without wrapping code in an async
function when using REPL mode in global evaluate. REPL mode evaluate
is changed to *always* return a Promise. The resolve value of the
promise is the completion value of the REPL script.

The implementation is based on two existing mechanisms:
  - Similar to async functions, the content of a REPL script is
    enclosed in a synthetic 'try' block. Any thrown error
    is used to reject the Promise of the REPL script.

  - The content of the synthetic 'try' block is also re-written the
    same way a normal script is. This is, artificial assignments to
    a ".result" variable are inserted to simulate a completion
    value. The difference for REPL scripts is, that ".result" is
    used to resolve the Promise of the REPL script.

  - ".result" is not returned directly but wrapped in an object
    literal: "{ .repl_result: .result}". This is done to prevent
    resolved promises from being chained and resolved prematurely:

    > Promse.resolve(42);

    should evaluate to a promise, not 42.

Bug: chromium:1021921
Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65273}
      5bddc0e1
  15. 28 Nov, 2019 1 commit
  17. 27 Nov, 2019 1 commit
  19. 25 Nov, 2019 2 commits
  21. 06 Nov, 2019 1 commit
    • Simon Zünd's avatar
      Introduce REPL mode · fbcc2e87
      Simon Zünd authored 
      Design doc: bit.ly/v8-repl-mode

This CL adds a new REPL mode that can be used via
DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration
of 'let' bindings at the moment. Example:

REPL Input 1: let x = 21;
REPL Input 2: let x = 42;

This would normally throw a SyntaxError, but works in REPL mode.

The implementation is done by:
  - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo}
    and script {Scope}.
  - Each global let declaration still gets a slot reserved in the
    respective {ScriptContext}.
  - When a new REPL mode {ScriptContext} is created, name clashes
    for let bindings are not reported as errors.
  - Declarations, loads and stores for global let in REPL mode are
    now "load/store global" instead of accessing their respective
    context slot directly. This causes a lookup in the ScriptContextTable
    where the found slot for each name is guaranteed to be the same
    (the first one).

Bug: chromium:1004193, chromium:1018158
Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64793}
      fbcc2e87
  23. 05 Nov, 2019 2 commits
  25. 09 Oct, 2019 1 commit
  27. 27 Sep, 2019 3 commits
    • Mythri A's avatar
      Reland "[compiler] Cache OSR optimized code" · fcff2437
      Mythri A authored 
      This is a reland of cfb10028
with a fix for failures in lite mode.

Original change's description:
> [compiler] Cache OSR optimized code
>
> With lazy feedback allocation, for functions that get OSRed we may
> not have feedback for the initial part of the functions since feedback
> vectors might be allocated after the function started executing. Hence
> we would not be able to optimize the function on the next call. This
> means we may have to OSR twice before we actually optimize function.
> This cl introduces OSR cache, so we could reuse the optimized code. One
> side effect of this cl is that the OSRed code won't be function context
> specialized anymore.
>
> Bug: chromium:987523
> Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64014}

Bug: chromium:987523
Change-Id: I9c782242b07b24d15247533ab4ee044334b429ff
TBR: rmcilroy@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826898
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64023}
      fcff2437
    • Michael Achenbach's avatar
      Revert "[compiler] Cache OSR optimized code" · f8a08223
      Michael Achenbach authored 
      This reverts commit cfb10028.

Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/6483

Original change's description:
> [compiler] Cache OSR optimized code
> 
> With lazy feedback allocation, for functions that get OSRed we may
> not have feedback for the initial part of the functions since feedback
> vectors might be allocated after the function started executing. Hence
> we would not be able to optimize the function on the next call. This
> means we may have to OSR twice before we actually optimize function.
> This cl introduces OSR cache, so we could reuse the optimized code. One
> side effect of this cl is that the OSRed code won't be function context
> specialized anymore.
> 
> Bug: chromium:987523
> Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64014}

TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org

Change-Id: Ib3692e7570bed5d3e88ca8a0247b185d70497a04
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:987523
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826668Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64015}
      f8a08223
    • Mythri A's avatar
      [compiler] Cache OSR optimized code · cfb10028
      Mythri A authored 
      With lazy feedback allocation, for functions that get OSRed we may
not have feedback for the initial part of the functions since feedback
vectors might be allocated after the function started executing. Hence
we would not be able to optimize the function on the next call. This
means we may have to OSR twice before we actually optimize function.
This cl introduces OSR cache, so we could reuse the optimized code. One
side effect of this cl is that the OSRed code won't be function context
specialized anymore.

Bug: chromium:987523
Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64014}
      cfb10028
  29. 05 Sep, 2019 1 commit
  31. 04 Sep, 2019 1 commit
    • Tobias Tebbi's avatar
      Revert "[compiler] improve inlining heuristics: call frequency per executed bytecodes" · eb443e1f
      Tobias Tebbi authored 
      This reverts commit 352a154e.

Reason for revert: https://crbug.com/999972

Original change's description:
> [compiler] improve inlining heuristics: call frequency per executed bytecodes
> 
> TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
> compile time including off-thread, while improving Octane scores by ~2%.
> 
> How things used to work:
> 
> There is a flag FLAG_min_inlining_frequency that limits inlining by
> the callsite being sufficiently frequently executed. This call frequency
> was measured relative to invocations of the parent (= the function we
> originally optimize). At the same time, the limit was very low (0.15),
> meaning we mostly relied on the total amount of inlined code
> (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
> 
> How things work now:
> 
> Instead of measuring call frequency relative to parent invocations, we
> should have a measure that predicts how often the callsite in question
> will be executed in the future. An obvious attempt at that would be to
> measure how often the callsite was executed in absolute numbers in the
> past. But depending on how fast feedback stabilizes, it can take more
> or less time until we optimize a function. If we just take the absolute
> call frequency up to the point in time when we optimize, we would
> inline more for functions that stabilize slowly, which doesn't make
> sense. So instead, we measure absolute call count per KB of executed
> bytecodes of the parent function.
> Since inlining big functions is more expensive, this threshold is
> additionally scaled linearly with the bytecode-size of the inlinee.
> The resulting formula is:
> call_frequency >
> FLAG_min_inlining_frequency *
>   (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
>   (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
> 
> The new threshold is chosen in a way that it effectively limits
> inlining, which allows us to increase
> FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
> in general.
> 
> The reduction in compile time (x64 build) of ~10% was observed in Octane,
> ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
> The hope is that this will reduce CPU-time in real-world situations
> too.
> The Octane improvements come from inlining more in places where it
> matters.
> 
> Bug: v8:6682
> 
> Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63449}

TBR=rmcilroy@chromium.org,neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org,mslekova@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:6682 chromium:999972
Change-Id: Iffca63d4bef81afa0f66e34d35fb72f3b5baf517
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784281Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63554}
      eb443e1f
  33. 30 Aug, 2019 1 commit
  35. 29 Aug, 2019 1 commit
    • Tobias Tebbi's avatar
      [compiler] improve inlining heuristics: call frequency per executed bytecodes · 352a154e
      Tobias Tebbi authored 
      TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
compile time including off-thread, while improving Octane scores by ~2%.

How things used to work:

There is a flag FLAG_min_inlining_frequency that limits inlining by
the callsite being sufficiently frequently executed. This call frequency
was measured relative to invocations of the parent (= the function we
originally optimize). At the same time, the limit was very low (0.15),
meaning we mostly relied on the total amount of inlined code
(FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.

How things work now:

Instead of measuring call frequency relative to parent invocations, we
should have a measure that predicts how often the callsite in question
will be executed in the future. An obvious attempt at that would be to
measure how often the callsite was executed in absolute numbers in the
past. But depending on how fast feedback stabilizes, it can take more
or less time until we optimize a function. If we just take the absolute
call frequency up to the point in time when we optimize, we would
inline more for functions that stabilize slowly, which doesn't make
sense. So instead, we measure absolute call count per KB of executed
bytecodes of the parent function.
Since inlining big functions is more expensive, this threshold is
additionally scaled linearly with the bytecode-size of the inlinee.
The resulting formula is:
call_frequency >
FLAG_min_inlining_frequency *
  (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
  (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)

The new threshold is chosen in a way that it effectively limits
inlining, which allows us to increase
FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
in general.

The reduction in compile time (x64 build) of ~10% was observed in Octane,
ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
The hope is that this will reduce CPU-time in real-world situations
too.
The Octane improvements come from inlining more in places where it
matters.

Bug: v8:6682

Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63449}
      352a154e
  37. 23 Aug, 2019 2 commits
  39. 13 Aug, 2019 1 commit
  41. 12 Aug, 2019 3 commits
  43. 08 Aug, 2019 1 commit
  45. 05 Aug, 2019 1 commit
    • Mythri A's avatar
      Reland "[ic] Don't transition to premonomorphic state" · 2999cea5
      Mythri A authored 
      This is a reland of 159df248

Original change's description:
> [ic] Don't transition to premonomorphic state
> 
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
> 
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
> 
> 
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}

Change-Id: Ica7eb65649615c2f8410d5b815a98b55cb1cfc4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731000
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63082}
      2999cea5
  47. 31 Jul, 2019 1 commit
  49. 17 Jul, 2019 1 commit
  51. 12 Jul, 2019 1 commit
  53. 11 Jul, 2019 1 commit
    • Mythri A's avatar
      Check that function was prepared before optimizing using manually · b086cb7b
      Mythri A authored 
      With lazy feedback allocation and bytecode flushing we need to call
%PrepareFunctionForOptimize before we call %OptimizeFunctionOnNextCall/
%OptimizeOsr. This cl:
1. Adds an additional state in pending optimized table to check if the
optimization was triggered manually.
2. Changes the compilation pipeline to delete the entry from pending
optimized table only if the optimization was triggered through
%OptimizeFunctionOnNextCall / %OptimizeOsr.
3. Adds a check to enforce %PrepareFunctionForOptimize was called.
4. Adds a new run-time flag to only check in the d8 test runner. We
don't want this check enabled in other cases like clusterfuzz that doesn't
ensure %PrepareFunctionForOptimize is called.

Bug: v8:8394, v8:8801, v8:9183
Change-Id: I9ae2b2da812e313c746b6df0b2da864c2ed5de51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664810
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62653}
      b086cb7b
  55. 27 Jun, 2019 1 commit
  57. 26 Jun, 2019 1 commit
  59. 14 Jun, 2019 1 commit
  61. 24 May, 2019 1 commit
  63. 23 May, 2019 2 commits