Skip to content

V
V8
Switch branch/tag
  1. 25 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [objects] Free one bit in the SharedFunctionInfo::flags. · 591408cb
      Benedikt Meurer authored 
      We'll need one bit in the SharedFunctionInfo::flags to record whether
it's safe to skip arguments adaptor frames (for v8:8895), so this
just removes the SharedFunctionInfo::IsDerivedConstructorBit which is
redundant, since the same information is already available in the
SharedFunctionInfo::FunctionKindBits, and most places in the code
use that already, with the exception of the JSConstructStubGeneric
builtin.

This changes the JSConstructStubGeneric builtin to just check the
function kind instead of testing the explicit bit, which also makes
this more consistent. It seems like there's not much overhead to
that, doing an additional bitmasking plus two comparisons instead
of one. This shouldn't really matter since invocation and execution
of the constructors is going to dominate and optimized code inlines
all of this anyways. If this turns out to affect performance, we
can still look into encoding the FunctionKindBits more cleverly.

Drive-by-fix: Move the FunctionKindBits first in the flags to avoid
the shift when accessing the function kind. This seems logic, since
for the actual boolean bit fields it doesn't matter where they are
in the flags, whereas for the function kind this saves one shift.

Bug: v8:8834, v8:8895
Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306
Reviewed-on: https://chromium-review.googlesource.com/c/1482915Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59821}
      591408cb
  3. 21 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Remove obsolete representations. · adb7e37b
      Benedikt Meurer authored 
      In the Crankshaft days we (mis)used the Representation to also express
the various internal representations that the compiler understands. But
with TurboFan we now have proper MachineRepresentation and MachineType,
which do that independently. So there's no need to have this in the
Representation class anymore, and instead the Representation class only
needs to deal with the field representations.

Bug: v8:8749, v8:8834, v8:8865
Change-Id: I34ea9558b5fdf20d6c7939b52762eaffd4316b06
Reviewed-on: https://chromium-review.googlesource.com/c/1479954
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59750}
      adb7e37b
  5. 15 Feb, 2019 1 commit
  7. 05 Feb, 2019 1 commit
  9. 17 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      Use forwarding constructors for MacroAssembler · edab9a20
      Clemens Hammacher authored 
      and TurboAssembler. Instead of listing all the different combinations
of arguments (which is one more now, temporarily), just forward all
arguments down via MacroAssembler and TurboAssembler to
TurboAssemblerBase.
Interestingly, this requires more specific types sometimes (int instead
of size_t), since further down the forwarding chain, the compiler does
not recognize any more that the value is a constant, and emits a
warning about a possibly truncating implicit conversion.

R=mstarzinger@chromium.org

Bug: v8:8689, v8:8562
Change-Id: Ifd13d2210ee64251c0075c0d9b68cacd5107d9ab
Reviewed-on: https://chromium-review.googlesource.com/c/1414913Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58869}
      edab9a20
  11. 08 Jan, 2019 1 commit
    • Ross McIlroy's avatar
      [Deopt] Remove jump table in prologue of deopt entries. · 4ab96a9a
      Ross McIlroy authored 
      Remove the use of a jump table in the prologue of the deopt entries
and instead pass the bailout id explicitly in a register when calling
the deopt entry routine from optimized code. This unifies the logic
with the way the Arm64 code works. It saves the following amount of
memory in code stubs:

 - arm:  384KB
 - ia32: 480KB
 - x64:  240KB

This could be offset by a slight increase in the size of optimized code
for loading the immediate, however this impact should be minimal and
will scale with the maximum number of bailout ids (e.g., the size of
code will increase by one instruction per bailout id on Arm, therefore
~98,000 bailouts will be needed before the overhead is greater than
the current fixed table size).

Change-Id: I838604b48fa04cbd45320c7b9dac0de08fd8eb25
Reviewed-on: https://chromium-review.googlesource.com/c/1398224
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58636}
      4ab96a9a
  13. 21 Dec, 2018 1 commit
  15. 17 Dec, 2018 2 commits
    • Jakob Gruber's avatar
      [nojit] Change builtin pointers to use Smis underneath · fa3cbf60
      Jakob Gruber authored 
      This changes Torque's builtin pointers to use a Smi representation
underneath instead of storing the Code target object. Callsites look
up the target entry point through IsolateData::builtin_entry_table.

The notable effect of this CL is that builtin pointer calls no longer
call any on-heap Code.

Bug: v8:7777
Change-Id: Ibf6c749dd46cae7aba51494b09921229dd436f63
Reviewed-on: https://chromium-review.googlesource.com/c/1379880
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58286}
      fa3cbf60
    • Jakob Gruber's avatar
      [nojit] Add a kCallBuiltinPointer call kind · f323a5f4
      Jakob Gruber authored 
      Currently, Torque's builtin pointers store a Code target underneath and
callsites generate a kArchCallCodeObject opcode. When embedded builtins
are enabled, the call thus first calls the on-heap trampoline, which
finally jumps to the target off-heap builtin code.

This will no longer be possible in jitless mode, since on-heap code must
not be executable.

As a step towards changing the way builtin pointers are called
(function pointers will hold the builtin index as a Smi, and callsites
look up the off-heap target address and jump there), this CL adds a
dedicated opcode for builtin pointer calls to the compiler pipeline.

The calling mechanism itself is unchanged, changes there will happen
in a follow-up.

Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'.

Bug: v8:7777
Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb
Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58281}
      f323a5f4
  17. 11 Dec, 2018 1 commit
  19. 07 Dec, 2018 4 commits
  21. 05 Dec, 2018 1 commit
  23. 29 Nov, 2018 2 commits
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 6c8b4102
      Peter Marshall authored 
      This is a reland of d5f4a33e
Landing with test disabled for now.

Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}

TBR=v8-mips-ports@googlegroups.com
TBR=jgruber@chromium.org

Bug: v8:8464, v8:7202
Change-Id: I260d5ab3bc12c9c4529fb52a297a1040dcaa8ebf
Reviewed-on: https://chromium-review.googlesource.com/c/1354466
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57935}
      6c8b4102
    • Michael Achenbach's avatar
      Revert "Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"" · 76786104
      Michael Achenbach authored 
      This reverts commit ddaa1f0a.

Reason for revert:
Still flaky on windows. Maybe reland and keep skipped on windows?
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20nosnap%20-%20shared/31002
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/27826

Original change's description:
> Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"
> 
> This is a reland of d5f4a33e
> 
> Original change's description:
> > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
> >
> > Before fast C calls, store the current FP and PC on the isolate. When
> > iterating frames in SafeStackFrameIterator, check if these fields are
> > set and start iterating at the calling frame's FP instead of the current
> > FP, which will be in C++ code. We need to do this because c_entry_fp is
> > not set on the Isolate for Fast-C-Calls because we don't build an exit
> > frame.
> >
> > This change makes stack samples that occur within 'Fast-C-Calls'
> > iterable, meaning we can properly attribute ticks within the JS caller.
> >
> > Fast-C-Calls can't call back into JS code, so we can only ever have one
> > such call on the stack at a time, allowing us to store the FP on the
> > isolate rather than the stack.
> >
> > TBR=v8-mips-ports@googlegroups.com
> >
> > Bug: v8:8464, v8:7202
> > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> > Reviewed-by: Alexei Filippov <alph@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#57896}
> 
> TBR=v8-mips-ports@googlegroups.com
> TBR=jgruber@chromium.org
> 
> Bug: v8:8464, v8:7202
> Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
> Reviewed-on: https://chromium-review.googlesource.com/c/1354042
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57912}

TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com

Change-Id: If810648dbf60df2ff70455b6e8ef466136c90145
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8464, v8:7202
Reviewed-on: https://chromium-review.googlesource.com/c/1354461Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57925}
      76786104
  25. 28 Nov, 2018 3 commits
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · ddaa1f0a
      Peter Marshall authored 
      This is a reland of d5f4a33e

Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}

TBR=v8-mips-ports@googlegroups.com
TBR=jgruber@chromium.org

Bug: v8:8464, v8:7202
Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
Reviewed-on: https://chromium-review.googlesource.com/c/1354042Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57912}
      ddaa1f0a
    • Maya Lekova's avatar
      Revert "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 2f530d5c
      Maya Lekova authored 
      This reverts commit d5f4a33e.

Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967

Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
> 
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
> 
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
> 
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
> 
> TBR=v8-mips-ports@googlegroups.com
> 
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}

TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com

Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8464, v8:7202
Reviewed-on: https://chromium-review.googlesource.com/c/1352302Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57899}
      2f530d5c
    • Peter Marshall's avatar
      [cpu-profiler] Fix stack iterability for fast C calls with no exit frame · d5f4a33e
      Peter Marshall authored 
      Before fast C calls, store the current FP and PC on the isolate. When
iterating frames in SafeStackFrameIterator, check if these fields are
set and start iterating at the calling frame's FP instead of the current
FP, which will be in C++ code. We need to do this because c_entry_fp is
not set on the Isolate for Fast-C-Calls because we don't build an exit
frame.

This change makes stack samples that occur within 'Fast-C-Calls'
iterable, meaning we can properly attribute ticks within the JS caller.

Fast-C-Calls can't call back into JS code, so we can only ever have one
such call on the stack at a time, allowing us to store the FP on the
isolate rather than the stack.

TBR=v8-mips-ports@googlegroups.com

Bug: v8:8464, v8:7202
Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
Reviewed-on: https://chromium-review.googlesource.com/c/1340241
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMartyn Capewell <martyn.capewell@arm.com>
Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57896}
      d5f4a33e
  27. 26 Nov, 2018 1 commit
  29. 23 Nov, 2018 1 commit
  31. 16 Nov, 2018 2 commits
  33. 09 Nov, 2018 1 commit
  35. 07 Nov, 2018 1 commit
  37. 05 Nov, 2018 1 commit
  39. 25 Oct, 2018 2 commits
  41. 19 Oct, 2018 1 commit
  43. 17 Oct, 2018 1 commit
  45. 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
  47. 10 Oct, 2018 1 commit
  49. 20 Sep, 2018 1 commit
  51. 03 Sep, 2018 1 commit
    • jgruber's avatar
      Remove isolate parameter from RecordWrite builtin · 62766423
      jgruber authored 
      The isolate can be efficiently loaded through other means: either as a
root-relative load (if embedded builtins are enabled), or as an embedded
external reference (i.e. the absolute pointer is included in the
instruction stream) otherwise.

The generated code should be at least as fast as previously. On x64
(with embedded builtins):

Before:
 // Register moves in prologue:
 0x7f47a6b4860a     a  488955e0       REX.W movq [rbp-0x20],rdx
 // And the load from a stack slot at each use-site.
 0x7f47a6b486f2    f2  488b7de0       REX.W movq rdi,[rbp-0x20]

After:
 // Each use-site just loads a root-relative offset.
 0x7f1645fcc6ce    ee  498dbd38ffffff REX.W leaq rdi,[r13-0xc8]

On ia32 (no embedded builtins), before:
 0x5c608930    10  8955f0         mov [ebp-0x10],edx
 0x5c6089fb    db  891424         mov [esp],edx

After:
 0x41d0898d    8d  b80033b156     mov eax,0x56b13300

Removal reduces register pressure, and frees up ebx as the root register
on ia32.

Note that the set of allocatable registers was only reduced on ia32 to
exclude the root register.

Bug: v8:6666
Change-Id: I14e401e2823c82042c76acae10c3c935b9982993
Reviewed-on: https://chromium-review.googlesource.com/1201586
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55587}
      62766423
  53. 23 Aug, 2018 1 commit
  55. 08 Aug, 2018 2 commits
  57. 07 Aug, 2018 1 commit
  59. 02 Aug, 2018 1 commit