Skip to content

V
V8
Switch branch/tag
  1. 08 Nov, 2021 1 commit
  3. 07 Oct, 2021 1 commit
  5. 29 Sep, 2021 1 commit
  7. 30 Aug, 2021 1 commit
  9. 24 Aug, 2021 1 commit
  11. 29 Jul, 2021 1 commit
    • Mythri A's avatar
      [sparkplug] Introduce flush_baseline_code flag · 64556d13
      Mythri A authored 
      Introduce a flush_baseline_code flag to control if baseline code is
flushed or not. Currently flush_baseline_code implies flush_bytecode
as well. So if flush_baseline_code is enabled both bytecode and baseline
code are flushed. If the flag is disabled we only flush bytecode and
not baseline code.

In a follow-up CL we will add support to control baseline and bytecode
flushing independently i.e. we can flush only bytecode / only baseline
code / both.

Bug: v8:11947
Change-Id: I5a90ed38469de64ed1d736d1eaaeabc2985f0783
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059684
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76003}
      64556d13
  13. 20 Jul, 2021 1 commit
    • Mythri A's avatar
      Reland "[sparkplug] Support bytecode / baseline code flushing with sparkplug" · 3ae733f9
      Mythri A authored 
      This is a reland of ea55438a. Relanding
after a fix lands here:
https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures
were caused because baseline code could be flushed during the process
of deoptimization after we choose which entry (InterpreterEnterAt* /
BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect
baseline code but it could be flushed before we execute the builtin. The
fix is to defer the decision.

Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}

Bug: v8:11947
Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75810}
      3ae733f9
  15. 19 Jul, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Make JSFunction bg-serialized · 0dba97f8
      Jakob Gruber authored 
      This wraps up the transition away from kSerialized ref kinds.

Since JSFunctionRef is a complex type, we don't attempt full
consistency on the background thread. Instead, we serialize functions
on the background in a partially-racy manner, in which consistency
between different JSFunction fields is *not* guaranteed. Consistency
is later verified through a new compilation dependency kind during
finalization.

Bug: v8:7790, v8:12004
Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75789}
      0dba97f8
  17. 12 Jul, 2021 2 commits
    • Mythri Alle's avatar
      Revert "[sparkplug] Support bytecode / baseline code flushing with sparkplug" · a079f057
      Mythri Alle authored 
      This reverts commit ea55438a.

Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview

Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}

Bug: v8:11947
Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75679}
      a079f057
    • Mythri A's avatar
      [sparkplug] Support bytecode / baseline code flushing with sparkplug · ea55438a
      Mythri A authored 
      Currently with sparkplug we don't flush bytecode / baseline code of
functions that were tiered up to sparkplug. This CL adds the support to
flush baseline code / bytecode of functions that have baseline code too.
This CL:
1. Updates the BodyDescriptor of JSFunction to treat the Code field of
JSFunction as a custom weak pointer where the code is treated as weak if
the bytecode corresponding to this function is old.
2. Updates GC to handle the functions that had a weak code object during
the atomic phase of GC.
3. Updates the check for old bytecode to also consider when there is
baseline code on the function.

This CL doesn't change any heuristics for flushing. The baseline code
will be flushed at the same time as bytecode.

Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
Bug: v8:11947
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75674}
      ea55438a
  19. 22 Jun, 2021 1 commit
  21. 17 Jun, 2021 1 commit
  23. 15 Jun, 2021 1 commit
  25. 07 Jun, 2021 1 commit
  27. 10 May, 2021 1 commit
  29. 04 May, 2021 1 commit
  31. 26 Apr, 2021 1 commit
  33. 15 Apr, 2021 1 commit
  35. 31 Mar, 2021 1 commit
  37. 17 Mar, 2021 2 commits
  39. 23 Feb, 2021 1 commit
  41. 22 Feb, 2021 1 commit
    • Mythri A's avatar
      [turboprop] Reduce BytecodeBudgetInterrupt overhead from Turboprop · 5b783479
      Mythri A authored 
      Earlier we used the same interrupt budget always and waited for higher
number of ticks when tiering up from Turboprop to TurboFan. On some of
the real world pages this adds a reasonable overhead for processing
these interrupts. This cl sets the interrupt budget to a higher value so
there are fewer interrupts. This cl:
1. Sets the interrupt budget on feedback cell to
FLAG_interrupt_budget * scale factor when we install optimized code.
2. Resets the budget to FLAG_interrupt_budget when there is a
deoptimization.
3. Updates the runtime profiler to remove the scaling of number of ticks
needed for optimization when tiering up from TP to TF.

On sheets benchmark, we spend 40-50ms when servicing interrupts from
Turboprop code. This change brings it down to ~7ms. We also see
improvements on other pages.


Bug: v8:9684
Change-Id: Ia3e5e998d1fff44f2e08a240a8769b7ebe794da2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696661
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72906}
      5b783479
  43. 19 Feb, 2021 1 commit
  45. 12 Feb, 2021 3 commits
  47. 29 Jan, 2021 1 commit
  49. 28 Jan, 2021 1 commit
    • Marja Hölttä's avatar
      Revert "Reland [super] Store home object in Context instead of JSFunction" · 12f8ac47
      Marja Hölttä authored 
      This reverts commit f6450b97.

Reason for revert: ClusterFuzz bugs

Original change's description:
> Reland [super] Store home object in Context instead of JSFunction
>
> 1) Computed property keys (esp functions in them) shouldn't be inside
> the object literal scope.
>
> 2) I was using an imprecise "maybe uses super" and storing it to
> preparse data. This won't fly, since it pollutes sister scopes and
> leads to confusion wrt whether an object literal needs a home object
> or not. Made it precise (mostly cancelling changes in the original CL).
>
> 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
> this_function (which made it used) -> inconsistent scopes between
> parsing and preparsing.
>
> 4) MultipleEntryBlockContextScope was messing up the accumulator
>
> Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
> Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72169}

TBR=marja@chromium.org,leszeks@chromium.org

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

Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72391}
      12f8ac47
  51. 27 Jan, 2021 1 commit
    • Mythri A's avatar
      Add option to allocate feedback vector based on bytecode size · aa4ee8d5
      Mythri A authored 
      Currently, feedback vectors are allocated on a fixed budget of 1024.
In some cases it might be beneficial to allocate feedback vectors based
on invocation count rather than fixed budget. For example, if we have
a large function that is only run once. This cl adds an option to
use interrupt budget based on the bytecode size. It kind of mimics
invocation count. We would allocate feedback vectors early when we
have loops which is also required.

This flag is turned off by default. In followup cl, we will enable it
and if the memory / performance tradeoff is good we might make it
default.

Change-Id: I9f7231119b5fd65fb3268e665e2e315fb2625e1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584960Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72371}
      aa4ee8d5
  53. 22 Jan, 2021 1 commit
  55. 19 Jan, 2021 2 commits
  57. 18 Jan, 2021 1 commit
  59. 15 Jan, 2021 1 commit
    • Mythri A's avatar
      Reland "[turboprop] Enable tierup to TurboFan with FLAG_turboprop" · 3a6920d2
      Mythri A authored 
      This is a reland of e38cb757. This
was reverted as a potential culprit for a wasm failure. The
actual revert that fixed the bots is here:
https://chromium-review.googlesource.com/c/v8/v8/+/2630736.
This should be safe to reland. I verified locally that the test is
failing with or without this change.

Original change's description:
> [turboprop] Enable tierup to TurboFan with FLAG_turboprop
>
> FLAG_turboprop was used to test the turboprop compiler without any
> further tierup to TurboFan. This cl changes:
> - FLAG_turboprop to also tier up to TurboFan.
> - Introduces FLAG_turboprop_as_toptier to continue running the
>   configuration without tierup.
> - Removes FLAG_turboprop_as_midtier which is same as FLAG_turboprop.
>
> Bug: v8:9684
> Change-Id: I487bda13d226434837770ecc43b3ced7c31ccf19
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622214
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72101}

Bug: v8:9684
Change-Id: I8b61fd8e562190c3c7bf5a003273f2a058542dad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632588
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72110}
      3a6920d2
  61. 14 Jan, 2021 2 commits
  63. 17 Dec, 2020 1 commit
  65. 05 Nov, 2020 1 commit
  67. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored 
      This CL splits the class definitions per .tq file, to realize the
following relationship:
A class defined in src/objects/foo.tq has a C++ definition in
src/objects/foo.h. Torque then generates:

- torque-generated/src/objects/foo-tq.inc
  An include file (no proper header) to be included in src/objects/foo.h
  containing the Torque-generated C++ class definition.

- torque-generated/src/objects/foo-tq-inl.inc
  An include file (no proper header) to be included in
  src/objects/foo-inl.h containing inline function definitions.

- torque-generated/src/objects/foo-tq.cc
  A source file including src/objects/foo-inl.h that contains non-inline
  function definitions.

Advantages of this approach:
- Avoid big monolithic headers and preserve the work that went into
  splitting objects.h
- Moving a definition to Torque keeps everything in the same place
  from a C++ viewpoint, including a fully Torque-generated C++ class
  definition.
- The Torque-generated include files do not need to be independent
  headers, necessary includes or forward declarations can just be added
  to the headers that include them.

Drive-by changes:
A bunch of definitions and files had to be moved or created to realize
a consistent 1:1 relationship between .tq files and C++ headers.


Bug: v8:7793
TBR: hpayer@chromium.org
Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296