Skip to content

V
V8
Switch branch/tag
  1. 11 Feb, 2021 1 commit
    • Benedikt Meurer's avatar
      [stack-traces] Remove StackFrameInfo. · 11b6f176
      Benedikt Meurer authored 
      For a long time, V8 had two distinct ways to capture and store a stack
trace, one where we'd just collect and symbolize the information for the
v8::StackTrace API (script id, name, line and colum information mostly),
and one where V8 would also memorize the closures, receivers, and
optionally the parameters of the stack frame, which we use for
Error.stack and the non-standard CallSite APIs. Those two were often out
of sync and suffered from various different issues. Eventually they were
refactored into a single captureStackTrace() bottleneck that would
produce a FrameArray.

This CL is a logical continuation of the refactorings. It repairs a
regression where we'd compute the method name (as part of the
cached StackFrameInfo) even if we don't need them (as is the case for
the inspector and any other use of the v8::StackTrace API).

Everytime a method was invoked on StackTraceFrame, it'd call into
StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo
like this:

  1. Create a FrameArrayIterator and point it to the FrameArray at the
     index stored in the StackTraceFrame.
  2. Invoke FrameArrayIterator::Frame(), which copies the information
     from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame
     or WasmStackFrame C++ object, and use the StackFrameBase virtual
     methods to transfer all information to a newly created
     StackFrameInfo object.
  3. Kill the link to the FrameArray and put a link to the
     StackFrameInfo object into the StackTraceFrame.

This caching turned out to be extremely costly, since beyond other
things, it'd always invoke JSStackFrame::GetMethodName(), which is
extremely costly (the execution time is linear in the number of
properties on the receiver and it's prototype chain). The cost was so
high that several work-arounds had been added, which would avoid
triggering the eager construction of the StackFrameInfo object (i.e.
https://crrev.com/c/2080663, https://crrev.com/c/2550504 or
https://crrev.com/c/2261736, but also https://crrev.com/c/1688927).

This CL removes the StackFrameInfo caching completely, since neither the
inspector nor Error.stack benefit from the caching at all. It's only the
first part in a series of refactorings that will significantly reduce
the complexity and overhead of the stack trace collection.

Doc: https://bit.ly/2wkbuIy
Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72647}
      11b6f176
  3. 10 Feb, 2021 1 commit
  5. 03 Feb, 2021 1 commit
  7. 01 Feb, 2021 1 commit
  9. 29 Jan, 2021 1 commit
  11. 26 Jan, 2021 1 commit
  13. 21 Jan, 2021 1 commit
  15. 20 Jan, 2021 1 commit
  17. 18 Jan, 2021 1 commit
  19. 17 Dec, 2020 1 commit
  21. 15 Dec, 2020 1 commit
  23. 24 Nov, 2020 1 commit
  25. 20 Nov, 2020 2 commits
  27. 19 Nov, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Introduce LocalIsolate for main thread" · dc45361e
      Dominik Inführ authored 
      This is a reland of e95e1b62

After landing https://crrev.com/c/2546682, this CL can be relanded
without changes.

Original change's description:
> [heap] Introduce LocalIsolate for main thread
>
> Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
> kept alive during the whole lifetime of the Isolate. The main thread
> LocalIsolate starts in the Running state in contrast to the background
> thread LocalIsolates (those start in Parked).
>
> Code paths in Turbofan that used to create a LocalIsolate on the main
> thread can now simply use the main thread LocalIsolate.
>
> LocalIsolate for the main thread will help in reducing differences
> between the main and background threads. The goal is that the main
> thread behaves more like a background thread.
>
> The main thread LocalIsolate should also make it simpler to share code
> between main thread and background threads by using LocalIsolate for
> both.
>
> Bug: v8:10315
> Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71226}

Bug: v8:10315
Change-Id: I418b1217aeac4f3c44a0aa514dea9864f8a58656
TBR: szuend@chromium.org, yangguo@chromium.org, ulan@chromium.org, leszeks@chromium.org, neis@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543399Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71274}
      dc45361e
  29. 17 Nov, 2020 4 commits
  31. 13 Nov, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [intl] Cache the last used formatter if possible · 4b139f76
      Sathya Gunasekaran authored 
      Instead of caching only the default formatter, cache the last used
formatter if possible.

This is better because it's a common use case to create a formatter
in a different language and reuse it a lot, rather than create
several formatters in various languages.

Running the following benchmark:
```
let i = 0;

function toLocaleString() {
  i++;
  return i.toLocaleString();
}

i = 0;
function toLocaleStringWithLocale() {
  i++;
  return i.toLocaleString('en-US');
}

const functions = [toLocaleString, toLocaleStringWithLocale];

for (const f of functions) {
  let start = performance.now();
  for (let i = 0; i < 10e5; i++) {
    f();
  }
  let end = performance.now();
  print(`${f.name}: ${end - start}`);
}
```
sees the following improvements:

With this patch:
  toLocaleString: 384.292
  toLocaleStringWithLocale: 450.48900000000003

Without this patch:
  toLocaleString: 341.952
  toLocaleStringWithLocale: 23439.694

This a little over 50x improvement.

Bug: chromium:926075
Change-Id: I0e316e959c90243e175df985854832a7abddbf54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536461
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71188}
      4b139f76
  33. 03 Nov, 2020 1 commit
  35. 02 Nov, 2020 2 commits
  37. 28 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      [embedded] Split blob hash into data/code hashes · 06b59094
      Jakob Gruber authored 
      .. and add a --text-is-readable flag to support non-readable .text
sections.

This splits the embedded blob hash into two dedicated hashes for data
and code sections. The main benefit is that we can now keep at least a
partial hash even with non-readable .text sections.

The second part of this CL adds a --text-is-readable runtime flag to
support such platforms (with non-readable .text).

It currently doesn't do much; setting it enables a few additional
DCHECKs, disables the constant pool on x64, and and disables
verification of the embedded blob's *code* hash.

Bug: v8:10707
Change-Id: Ib91ed8b50b50f2cd81677f62920bea6fb92af453
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504251Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70827}
      06b59094
  39. 27 Oct, 2020 2 commits
    • Mike Stanton's avatar
      [TurboFan] Provide concurrent access to feedback vector · 2288b1f6
      Mike Stanton authored 
      This CL provides synchronized get/set to feedback vector slots.
The FeedbackNexus is set up to use order preserving reads when used
on the background thread, and a lock to ensure coherent read
of information for ICKinds with two slots. The main thread takes
the lock on sets.

This test provides patterns to be followed by concurrent TurboFan.

We don't yet access the FeedbackVector on the background thread.
This CL only makes it safe to do so. The next step will come when
the optimizing compiler begins to query the the vector from the
background thread. Currently, with --concurrent-inlining turned on
this is done in bytecode serialization on the main thread. Without
concurrent inlining, it's also done on the main thread, in both
cases using the FeedbackNexus.

Bug: v8:7790
Change-Id: I49d8b8031190f91a0da1c24f375b6b6d8a9fe038
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2276210
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70797}
      2288b1f6
    • Jakob Gruber's avatar
      [code] Extend comments, use better terms to describe metadata · 23ba0667
      Jakob Gruber authored 
      This addresses comments from [0] by extending comments to also
describe embedded builtins in code.h, and by improving language
around various meaning of 'metadata':

- The Code object's metadata section is still called 'metadata'.
- The embedded blob's table of layout descriptions for builtins is
  now called 'layout descriptions'.
- The embedded blob's data section (containing hashes and layout
  descriptions) is now called 'data' section.

[0] chromium-review.googlesource.com/c/v8/v8/+/2491025

Bug: v8:11036
Change-Id: Ibe84fddb9784cc5d3b66482612dcdb7a2e8d14ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501284
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70793}
      23ba0667
  41. 26 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      Reland "[code] Separate instruction and metadata areas" · a4449f26
      Jakob Gruber authored 
      This is a reland of b66993bc

Nothing changed in the reland, the original CL was not the
culprit for win32 failures. They started earlier, at
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/29444

Original change's description:
> [code] Separate instruction and metadata areas
>
> In this CL, Code object layout changes s.t. the instruction
> area is distinct / non-overlapping from the metadata area.
>
> On-heap Code objects now have a variable-size `body` area,
> containing distinct-but-adjacent `instruction` and `metadata`
> areas.
>
> Off-heap code (= embedded builtins) currently have the same,
> but in the future the metadata area will move elsewhere and
> no longer be adjacent to instructions.
>
> To implement this, the main changes are:
>
>  - The Code object header now contains instruction and metadata
>    sizes, and no longer contains the safepoint table offset
>    (it's implicitly the first table of the metadata section).
>  - The embedded metadata table contains information about both
>    instruction and metadata areas.
>
> I've also added assertions in spots that currently rely on a
> contiguous body area.
>
> Bug: v8:11036
> Change-Id: I940f0c70c07ad511dafd2d2c3e337de8c92cd4b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491025
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70743}

No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Tbr: leszeks@chromium.org, clemensb@chromium.org, dinfuehr@chromium.org
Bug: v8:11036
Change-Id: I238562d7e25cf28cc689856ee8b17f25627aaee7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497162
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70747}
      a4449f26
  43. 25 Oct, 2020 2 commits
    • Zhi An Ng's avatar
      Revert "[code] Separate instruction and metadata areas" · 9a02964a
      Zhi An Ng authored 
      This reverts commit b66993bc.

Reason for revert: Broke v8 win32 https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/29454?

Original change's description:
> [code] Separate instruction and metadata areas
>
> In this CL, Code object layout changes s.t. the instruction
> area is distinct / non-overlapping from the metadata area.
>
> On-heap Code objects now have a variable-size `body` area,
> containing distinct-but-adjacent `instruction` and `metadata`
> areas.
>
> Off-heap code (= embedded builtins) currently have the same,
> but in the future the metadata area will move elsewhere and
> no longer be adjacent to instructions.
>
> To implement this, the main changes are:
>
>  - The Code object header now contains instruction and metadata
>    sizes, and no longer contains the safepoint table offset
>    (it's implicitly the first table of the metadata section).
>  - The embedded metadata table contains information about both
>    instruction and metadata areas.
>
> I've also added assertions in spots that currently rely on a
> contiguous body area.
>
> Bug: v8:11036
> Change-Id: I940f0c70c07ad511dafd2d2c3e337de8c92cd4b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491025
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70743}

TBR=jgruber@chromium.org,leszeks@chromium.org,clemensb@chromium.org,dinfuehr@chromium.org

Change-Id: Ia52ac609a47b8a2038a2511f0af8526ebdfe4719
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11036
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497381Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70744}
      9a02964a
    • Jakob Gruber's avatar
      [code] Separate instruction and metadata areas · b66993bc
      Jakob Gruber authored 
      In this CL, Code object layout changes s.t. the instruction
area is distinct / non-overlapping from the metadata area.

On-heap Code objects now have a variable-size `body` area,
containing distinct-but-adjacent `instruction` and `metadata`
areas.

Off-heap code (= embedded builtins) currently have the same,
but in the future the metadata area will move elsewhere and
no longer be adjacent to instructions.

To implement this, the main changes are:

 - The Code object header now contains instruction and metadata
   sizes, and no longer contains the safepoint table offset
   (it's implicitly the first table of the metadata section).
 - The embedded metadata table contains information about both
   instruction and metadata areas.

I've also added assertions in spots that currently rely on a
contiguous body area.

Bug: v8:11036
Change-Id: I940f0c70c07ad511dafd2d2c3e337de8c92cd4b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491025Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70743}
      b66993bc
  45. 24 Oct, 2020 1 commit
    • Camillo Bruni's avatar
      Reland "[runtime] Use Isolate::ThrowAt with MessageLocation" · 447915ef
      Camillo Bruni authored 
      This is a reland of eb6b4ce1

Skip test that serializes Error which references a Script. All errors
created by ThrowAt store the current Script under the
error_script_symbol.

Original change's description:
> [runtime] Use Isolate::ThrowAt with MessageLocation
>
> Fix various missing source positions when reporting parse and compile
> errors. Namely this fixes missing source positions when having invalid
> module imports.
>
> - Use Isolate::ThrowAt with valid MessageLocation objects
> - Change public Isolate::Throw to no longer accept MessageLocation to
>   avoid misues
> - Introduce private Isolate::ThrowInternal that accepts MessageLocation
>
> Bug: v8:6513
> Change-Id: I3ee633c9fff8c9d361bddb37f56e28a50c280ec1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467839
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70623}

Bug: v8:6513
Change-Id: Icba74f74178e28fbda0fd0c237eeb7bacbc33570
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487123Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70741}
      447915ef
  47. 22 Oct, 2020 1 commit
  49. 21 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      Reland "Reland "[deoptimizer] Change deopt entries into builtins"" · c7cb9bec
      Jakob Gruber authored 
      This is a reland of fbfa9bf4

The arm64 was missing proper codegen for CFI, thus sizes were off.

Original change's description:
> Reland "[deoptimizer] Change deopt entries into builtins"
>
> This is a reland of 7f58ced7
>
> It fixes the different exit size emitted on x64/Atom CPUs due to
> performance tuning in TurboAssembler::Call. Additionally, add
> cctests to verify the fixed size exits.
>
> Original change's description:
> > [deoptimizer] Change deopt entries into builtins
> >
> > While the overall goal of this commit is to change deoptimization
> > entries into builtins, there are multiple related things happening:
> >
> > - Deoptimization entries, formerly stubs (i.e. Code objects generated
> >   at runtime, guaranteed to be immovable), have been converted into
> >   builtins. The major restriction is that we now need to preserve the
> >   kRootRegister, which was formerly used on most architectures to pass
> >   the deoptimization id. The solution differs based on platform.
> > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> > - Removed heap/ support for immovable Code generation.
> > - Removed the DeserializerData class (no longer needed).
> > - arm64: to preserve 4-byte deopt exits, introduced a new optimization
> >   in which the final jump to the deoptimization entry is generated
> >   once per Code object, and deopt exits can continue to emit a
> >   near-call.
> > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
> >   sizes by 4/8, 5, and 5 bytes, respectively.
> >
> > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> > by using the same strategy as on arm64 (recalc deopt id from return
> > address). Before:
> >
> >  e300a002       movw r10, <id>
> >  e59fc024       ldr ip, [pc, <entry offset>]
> >  e12fff3c       blx ip
> >
> > After:
> >
> >  e59acb35       ldr ip, [r10, <entry offset>]
> >  e12fff3c       blx ip
> >
> > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> > with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> > object (max 32 bytes added overhead per Code object). Before:
> >
> >  9401cdae       bl <entry offset>
> >
> > After:
> >
> >  # eager deoptimization entry jump.
> >  f95b1f50       ldr x16, [x26, <eager entry offset>]
> >  d61f0200       br x16
> >  # lazy deoptimization entry jump.
> >  f95b2b50       ldr x16, [x26, <lazy entry offset>]
> >  d61f0200       br x16
> >  # the deopt exit.
> >  97fffffc       bl <eager deoptimization entry jump offset>
> >
> > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
> >
> >  bb00000000     mov ebx,<id>
> >  e825f5372b     call <entry>
> >
> > After:
> >
> >  e8ea2256ba     call <entry>
> >
> > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
> >
> >  49c7c511000000 REX.W movq r13,<id>
> >  e8ea2f0700     call <entry>
> >
> > After:
> >
> >  41ff9560360000 call [r13+<entry offset>]
> >
> > Bug: v8:8661,v8:8768
> > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70597}
>
> Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
> Bug: v8:8661,v8:8768,chromium:1140165
> Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70655}

Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
Bug: v8:8661
Bug: v8:8768
Bug: chromium:1140165
Change-Id: I471cc94fc085e527dc9bfb5a84b96bd907c2333f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488682Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70672}
      c7cb9bec
  51. 20 Oct, 2020 6 commits
    • Maya Lekova's avatar
      Revert "Reland "[deoptimizer] Change deopt entries into builtins"" · 7c7aa4fa
      Maya Lekova authored 
      This reverts commit fbfa9bf4.

Reason for revert: Seems to break arm64 sim CFI build (please see DeoptExitSizeIfFixed) - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/2808

Original change's description:
> Reland "[deoptimizer] Change deopt entries into builtins"
>
> This is a reland of 7f58ced7
>
> It fixes the different exit size emitted on x64/Atom CPUs due to
> performance tuning in TurboAssembler::Call. Additionally, add
> cctests to verify the fixed size exits.
>
> Original change's description:
> > [deoptimizer] Change deopt entries into builtins
> >
> > While the overall goal of this commit is to change deoptimization
> > entries into builtins, there are multiple related things happening:
> >
> > - Deoptimization entries, formerly stubs (i.e. Code objects generated
> >   at runtime, guaranteed to be immovable), have been converted into
> >   builtins. The major restriction is that we now need to preserve the
> >   kRootRegister, which was formerly used on most architectures to pass
> >   the deoptimization id. The solution differs based on platform.
> > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> > - Removed heap/ support for immovable Code generation.
> > - Removed the DeserializerData class (no longer needed).
> > - arm64: to preserve 4-byte deopt exits, introduced a new optimization
> >   in which the final jump to the deoptimization entry is generated
> >   once per Code object, and deopt exits can continue to emit a
> >   near-call.
> > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
> >   sizes by 4/8, 5, and 5 bytes, respectively.
> >
> > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> > by using the same strategy as on arm64 (recalc deopt id from return
> > address). Before:
> >
> >  e300a002       movw r10, <id>
> >  e59fc024       ldr ip, [pc, <entry offset>]
> >  e12fff3c       blx ip
> >
> > After:
> >
> >  e59acb35       ldr ip, [r10, <entry offset>]
> >  e12fff3c       blx ip
> >
> > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> > with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> > object (max 32 bytes added overhead per Code object). Before:
> >
> >  9401cdae       bl <entry offset>
> >
> > After:
> >
> >  # eager deoptimization entry jump.
> >  f95b1f50       ldr x16, [x26, <eager entry offset>]
> >  d61f0200       br x16
> >  # lazy deoptimization entry jump.
> >  f95b2b50       ldr x16, [x26, <lazy entry offset>]
> >  d61f0200       br x16
> >  # the deopt exit.
> >  97fffffc       bl <eager deoptimization entry jump offset>
> >
> > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
> >
> >  bb00000000     mov ebx,<id>
> >  e825f5372b     call <entry>
> >
> > After:
> >
> >  e8ea2256ba     call <entry>
> >
> > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
> >
> >  49c7c511000000 REX.W movq r13,<id>
> >  e8ea2f0700     call <entry>
> >
> > After:
> >
> >  41ff9560360000 call [r13+<entry offset>]
> >
> > Bug: v8:8661,v8:8768
> > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70597}
>
> Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
> Bug: v8:8661,v8:8768,chromium:1140165
> Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70655}

TBR=ulan@chromium.org,rmcilroy@chromium.org,jgruber@chromium.org,tebbi@chromium.org

Change-Id: I4739a3475bfd8ee0cfbe4b9a20382f91a6ef1bf0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8661
Bug: v8:8768
Bug: chromium:1140165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485223Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70658}
      7c7aa4fa
    • Jakob Gruber's avatar
      Reland "[deoptimizer] Change deopt entries into builtins" · fbfa9bf4
      Jakob Gruber authored 
      This is a reland of 7f58ced7

It fixes the different exit size emitted on x64/Atom CPUs due to
performance tuning in TurboAssembler::Call. Additionally, add
cctests to verify the fixed size exits.

Original change's description:
> [deoptimizer] Change deopt entries into builtins
>
> While the overall goal of this commit is to change deoptimization
> entries into builtins, there are multiple related things happening:
>
> - Deoptimization entries, formerly stubs (i.e. Code objects generated
>   at runtime, guaranteed to be immovable), have been converted into
>   builtins. The major restriction is that we now need to preserve the
>   kRootRegister, which was formerly used on most architectures to pass
>   the deoptimization id. The solution differs based on platform.
> - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> - Removed heap/ support for immovable Code generation.
> - Removed the DeserializerData class (no longer needed).
> - arm64: to preserve 4-byte deopt exits, introduced a new optimization
>   in which the final jump to the deoptimization entry is generated
>   once per Code object, and deopt exits can continue to emit a
>   near-call.
> - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
>   sizes by 4/8, 5, and 5 bytes, respectively.
>
> On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> by using the same strategy as on arm64 (recalc deopt id from return
> address). Before:
>
>  e300a002       movw r10, <id>
>  e59fc024       ldr ip, [pc, <entry offset>]
>  e12fff3c       blx ip
>
> After:
>
>  e59acb35       ldr ip, [r10, <entry offset>]
>  e12fff3c       blx ip
>
> On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> object (max 32 bytes added overhead per Code object). Before:
>
>  9401cdae       bl <entry offset>
>
> After:
>
>  # eager deoptimization entry jump.
>  f95b1f50       ldr x16, [x26, <eager entry offset>]
>  d61f0200       br x16
>  # lazy deoptimization entry jump.
>  f95b2b50       ldr x16, [x26, <lazy entry offset>]
>  d61f0200       br x16
>  # the deopt exit.
>  97fffffc       bl <eager deoptimization entry jump offset>
>
> On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
>
>  bb00000000     mov ebx,<id>
>  e825f5372b     call <entry>
>
> After:
>
>  e8ea2256ba     call <entry>
>
> On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
>
>  49c7c511000000 REX.W movq r13,<id>
>  e8ea2f0700     call <entry>
>
> After:
>
>  41ff9560360000 call [r13+<entry offset>]
>
> Bug: v8:8661,v8:8768
> Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70597}

Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
Bug: v8:8661,v8:8768,chromium:1140165
Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70655}
      fbfa9bf4
    • Jakob Gruber's avatar
      Revert "[deoptimizer] Change deopt entries into builtins" · 8bc9a794
      Jakob Gruber authored 
      This reverts commit 7f58ced7.

Reason for revert: Segfaults on Atom_x64 https://ci.chromium.org/p/v8-internal/builders/ci/v8_linux64_atom_perf/5686?

Original change's description:
> [deoptimizer] Change deopt entries into builtins
>
> While the overall goal of this commit is to change deoptimization
> entries into builtins, there are multiple related things happening:
>
> - Deoptimization entries, formerly stubs (i.e. Code objects generated
>   at runtime, guaranteed to be immovable), have been converted into
>   builtins. The major restriction is that we now need to preserve the
>   kRootRegister, which was formerly used on most architectures to pass
>   the deoptimization id. The solution differs based on platform.
> - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> - Removed heap/ support for immovable Code generation.
> - Removed the DeserializerData class (no longer needed).
> - arm64: to preserve 4-byte deopt exits, introduced a new optimization
>   in which the final jump to the deoptimization entry is generated
>   once per Code object, and deopt exits can continue to emit a
>   near-call.
> - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
>   sizes by 4/8, 5, and 5 bytes, respectively.
>
> On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> by using the same strategy as on arm64 (recalc deopt id from return
> address). Before:
>
>  e300a002       movw r10, <id>
>  e59fc024       ldr ip, [pc, <entry offset>]
>  e12fff3c       blx ip
>
> After:
>
>  e59acb35       ldr ip, [r10, <entry offset>]
>  e12fff3c       blx ip
>
> On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> object (max 32 bytes added overhead per Code object). Before:
>
>  9401cdae       bl <entry offset>
>
> After:
>
>  # eager deoptimization entry jump.
>  f95b1f50       ldr x16, [x26, <eager entry offset>]
>  d61f0200       br x16
>  # lazy deoptimization entry jump.
>  f95b2b50       ldr x16, [x26, <lazy entry offset>]
>  d61f0200       br x16
>  # the deopt exit.
>  97fffffc       bl <eager deoptimization entry jump offset>
>
> On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
>
>  bb00000000     mov ebx,<id>
>  e825f5372b     call <entry>
>
> After:
>
>  e8ea2256ba     call <entry>
>
> On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
>
>  49c7c511000000 REX.W movq r13,<id>
>  e8ea2f0700     call <entry>
>
> After:
>
>  41ff9560360000 call [r13+<entry offset>]
>
> Bug: v8:8661,v8:8768
> Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70597}

TBR=ulan@chromium.org,rmcilroy@chromium.org,jgruber@chromium.org,tebbi@chromium.org

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

Bug: v8:8661,v8:8768,chromium:1140165
Change-Id: I3df02ab42f6e02233d9f6fb80e8bb18f76870d91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485504Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70649}
      8bc9a794
    • Jakob Gruber's avatar
      Reland "[code] Move the unwinding info into metadata area" · 82f6863a
      Jakob Gruber authored 
      This is a reland of c5379162

The reland fixes Code::clear_padding to correctly clear trailing
padding.

Original change's description:
> [code] Move the unwinding info into metadata area
>
> Semantically, the unwinding info is a variable-size metadata table
> with untagged (i.e. no relocation needed) contents, packed inside Code
> objects. This is just like other metadata tables (safepoint table,
> handler table, constant pool, code comments); but for historical
> reasons it's been treated differently so far. Unlike these other
> tables, the unwinding info was located *after* InstructionEnd, and its
> size was written to the first 8 bytes after InstructionEnd.
>
> This CL makes unwinding info handling more consistent with other
> metadata tables by writing its offset into a dedicated
> kUnwindingInfoOffsetOffset header slot, and by moving the actual data
> inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
> this area will be split into dedicated instruction- and metadata
> areas.
>
> A picture is worth 1000 words, before:
>
>  +--------------------------+  <-- raw_instruction_start()
>  |       instructions       |
>  |           ...            |
>  +--------------------------+
>  |     embedded metadata    |  <-- safepoint_table_offset()
>  |           ...            |  <-- handler_table_offset()
>  |                          |  <-- constant_pool_offset()
>  |                          |  <-- code_comments_offset()
>  |    padding to the next   |
>  |  8-byte aligned address  |
>  +--------------------------+  <-- raw_instruction_end()
>  |   [unwinding_info_size]  |
>  |        as uint64_t       |
>  +--------------------------+  <-- unwinding_info_start()
>  |       unwinding info     |
>  |            ...           |
>  +--------------------------+  <-- unwinding_info_end()
>
> After:
>
>  +--------------------------+  <-- raw_instruction_start()
>  |       instructions       |
>  |           ...            |
>  +--------------------------+
>  |     embedded metadata    |  <-- safepoint_table_offset()
>  |           ...            |  <-- handler_table_offset()
>  |                          |  <-- constant_pool_offset()
>  |                          |  <-- code_comments_offset()
>  |                          |  <-- unwinding_info_offset()
>  |                          |
>  +--------------------------+  <-- raw_instruction_end()
>
> Bug: v8:11036
> Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70640}

Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Tbr: leszeks@chromium.org
Bug: v8:11036
Change-Id: I2ea056fe2a53217e0b5ae25661b92f5ddec6fca5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485501
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70645}
      82f6863a
    • Maya Lekova's avatar
      Revert "[code] Move the unwinding info into metadata area" · adf5c707
      Maya Lekova authored 
      This reverts commit c5379162.

Reason for revert: Seems to cause MSAN failure - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34931

Original change's description:
> [code] Move the unwinding info into metadata area
>
> Semantically, the unwinding info is a variable-size metadata table
> with untagged (i.e. no relocation needed) contents, packed inside Code
> objects. This is just like other metadata tables (safepoint table,
> handler table, constant pool, code comments); but for historical
> reasons it's been treated differently so far. Unlike these other
> tables, the unwinding info was located *after* InstructionEnd, and its
> size was written to the first 8 bytes after InstructionEnd.
>
> This CL makes unwinding info handling more consistent with other
> metadata tables by writing its offset into a dedicated
> kUnwindingInfoOffsetOffset header slot, and by moving the actual data
> inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
> this area will be split into dedicated instruction- and metadata
> areas.
>
> A picture is worth 1000 words, before:
>
>  +--------------------------+  <-- raw_instruction_start()
>  |       instructions       |
>  |           ...            |
>  +--------------------------+
>  |     embedded metadata    |  <-- safepoint_table_offset()
>  |           ...            |  <-- handler_table_offset()
>  |                          |  <-- constant_pool_offset()
>  |                          |  <-- code_comments_offset()
>  |    padding to the next   |
>  |  8-byte aligned address  |
>  +--------------------------+  <-- raw_instruction_end()
>  |   [unwinding_info_size]  |
>  |        as uint64_t       |
>  +--------------------------+  <-- unwinding_info_start()
>  |       unwinding info     |
>  |            ...           |
>  +--------------------------+  <-- unwinding_info_end()
>
> After:
>
>  +--------------------------+  <-- raw_instruction_start()
>  |       instructions       |
>  |           ...            |
>  +--------------------------+
>  |     embedded metadata    |  <-- safepoint_table_offset()
>  |           ...            |  <-- handler_table_offset()
>  |                          |  <-- constant_pool_offset()
>  |                          |  <-- code_comments_offset()
>  |                          |  <-- unwinding_info_offset()
>  |                          |
>  +--------------------------+  <-- raw_instruction_end()
>
> Bug: v8:11036
> Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70640}

TBR=jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org

Change-Id: If8417f88f4c55771e455ec85f5efdc6343671ad3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11036
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485500Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70641}
      adf5c707
    • Jakob Gruber's avatar
      [code] Move the unwinding info into metadata area · c5379162
      Jakob Gruber authored 
      Semantically, the unwinding info is a variable-size metadata table
with untagged (i.e. no relocation needed) contents, packed inside Code
objects. This is just like other metadata tables (safepoint table,
handler table, constant pool, code comments); but for historical
reasons it's been treated differently so far. Unlike these other
tables, the unwinding info was located *after* InstructionEnd, and its
size was written to the first 8 bytes after InstructionEnd.

This CL makes unwinding info handling more consistent with other
metadata tables by writing its offset into a dedicated
kUnwindingInfoOffsetOffset header slot, and by moving the actual data
inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
this area will be split into dedicated instruction- and metadata
areas.

A picture is worth 1000 words, before:

 +--------------------------+  <-- raw_instruction_start()
 |       instructions       |
 |           ...            |
 +--------------------------+
 |     embedded metadata    |  <-- safepoint_table_offset()
 |           ...            |  <-- handler_table_offset()
 |                          |  <-- constant_pool_offset()
 |                          |  <-- code_comments_offset()
 |    padding to the next   |
 |  8-byte aligned address  |
 +--------------------------+  <-- raw_instruction_end()
 |   [unwinding_info_size]  |
 |        as uint64_t       |
 +--------------------------+  <-- unwinding_info_start()
 |       unwinding info     |
 |            ...           |
 +--------------------------+  <-- unwinding_info_end()

After:

 +--------------------------+  <-- raw_instruction_start()
 |       instructions       |
 |           ...            |
 +--------------------------+
 |     embedded metadata    |  <-- safepoint_table_offset()
 |           ...            |  <-- handler_table_offset()
 |                          |  <-- constant_pool_offset()
 |                          |  <-- code_comments_offset()
 |                          |  <-- unwinding_info_offset()
 |                          |
 +--------------------------+  <-- raw_instruction_end()

Bug: v8:11036
Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70640}
      c5379162
  53. 19 Oct, 2020 2 commits