Skip to content

V
V8
Switch branch/tag
  1. 20 Oct, 2017 1 commit
  3. 18 Oct, 2017 6 commits
  5. 13 Oct, 2017 1 commit
  7. 12 Oct, 2017 1 commit
  9. 11 Oct, 2017 2 commits
  11. 10 Oct, 2017 2 commits
  13. 04 Oct, 2017 1 commit
  15. 02 Oct, 2017 1 commit
  17. 29 Sep, 2017 1 commit
  19. 27 Sep, 2017 1 commit
  21. 22 Sep, 2017 1 commit
  23. 15 Sep, 2017 1 commit
  25. 12 Sep, 2017 1 commit
  27. 11 Sep, 2017 1 commit
  29. 07 Sep, 2017 1 commit
    • jgruber's avatar
      [builtins] Move DeserializeLazy to ASM · e67420cb
      jgruber authored 
      There are two main reasons to move DeserializeLazy to ASM:

1. We avoid complications around the distinction between Call/Construct
   cases by making sure relevant registers (e.g. new_target) remain
   unclobbered.

2. We can avoid the tail-call through CodeFactory::Call/Construct by
   jumping directly to the deserialized code object.

Bug: v8:6624
Change-Id: Idef8fa73d804e16d510f62766c735d1891729b81
Reviewed-on: https://chromium-review.googlesource.com/652472Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47876}
      e67420cb
  31. 05 Sep, 2017 2 commits
    • Ross McIlroy's avatar
      [Interpreter] Remove InterpreterExitTrampoline. · 30f08f39
      Ross McIlroy authored 
      Always return to the InterpreterEntryTrampoline rather than calling the
InterpreterExitTrampoline from the Return bytecode handler. This fixes a
regression which occured if we upset the call/return stack by skipping the
return to the InterpreterEntryTrampoline from the return bytecode handler.

BUG=chromium:759390,chromium:753705

Change-Id: Ib625654a4a5072ac6c8d8e9611d1b9c0bbced4ca
Reviewed-on: https://chromium-review.googlesource.com/649517
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47826}
      30f08f39
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · f0acede9
      Juliana Franco authored 
      This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.

No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
 
We needed to change/remove the cctests that used to check
something on this list.
 
Working in x64, ia32, arm64, arm, mips64 and mips. 
 

Bug: v8:6637
Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
TBR: mstarzinger@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/647596
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47808}
      f0acede9
  33. 04 Sep, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "Remove weak-list of optimized JS functions." · 36b50283
      Michael Achenbach authored 
      This reverts commit 84c2dfce.

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876

Original change's description:
> Remove weak-list of optimized JS functions.
> 
> This CL removes the weak-list of JS functions from the context
> and all the code that iterares over it. This list was being used
> mainly during deoptimization (for code unlinking) and during
> garbage collection. Removing it will improve performance of
> programs that create many closures and trigger many scavenge GC
> cycles.
> 
> No extra work is required during garbage collection. However,
> given that we no longer unlink code from JS functions during
> deoptimization, we leave it as it is, and on its next activation
> we check whether the mark_for_deoptimization bit of that code is
> set, and if it is, than we unlink it and jump to lazy compiled
> code. This check happens in the prologue of every code object.
> 
> We needed to change/remove the cctests that used to check
> something on this list.
> 
> Working in x64, ia32, arm64, arm, mips64 and mips. 
> 
> Bug: v8:6637
> Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
> Reviewed-on: https://chromium-review.googlesource.com/600427
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47790}

TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com

Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6637
Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47792}
      36b50283
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · 84c2dfce
      Juliana Franco authored 
      This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.

No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.

We needed to change/remove the cctests that used to check
something on this list.

Working in x64, ia32, arm64, arm, mips64 and mips. 

Bug: v8:6637
Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
Reviewed-on: https://chromium-review.googlesource.com/600427
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47790}
      84c2dfce
  35. 25 Aug, 2017 2 commits
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored 
      This change adapts the Call bytecode handlers such that they don't require
a stack frame. It does this by modifying the call bytecode handler to
tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
callee function will return to the InterpreterEntryTrampoline when it returns
(since this is the return address on the interpreter frame), which is
adapted to dispatch to the next bytecode handler. The return bytecode
handler is modified to tail-call a new InterpreterExitTramoline instead
of returning to the InterpreterEntryTrampoline.

Overall this significanlty reduces the amount of stack space required for
interpreter frames, increasing the maximum depth of recursive calls from
around 6000 to around 12,500 on x64.

BUG=chromium:753705

Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
Reviewed-on: https://chromium-review.googlesource.com/634364
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140
    • Shiyu Zhang's avatar
      [builtins] Create new builtins to set up args for CPP/API builtins · ce1639d8
      Shiyu Zhang authored 
      The CPP builtins execute the same piece of code to prepare context before
jumping into CEntryStub. By creating new ASM builtin to execute that common
piece of code, ~7KB code size (tested on x64) of snapshot_blob.bin can be 
reduced without any negative performance impact.

BUG=

Change-Id: I744369e8723dcd902b61dc50645db66bea884441
Reviewed-on: https://chromium-review.googlesource.com/595119Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47590}
      ce1639d8
  37. 24 Aug, 2017 1 commit
  39. 23 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      Reland "[Compiler] Remove code aging support." · 8bf15bf1
      Ross McIlroy authored 
      > This reverts commit 42d3d36b.
> 
> Original change's description:
> > [Compiler] Remove code aging support.
> > 
> > Code aging is no longer supported by any remaining compilers now
> > that full codegen has been removed. This CL removes all vestiges of
> > code aging.
> > 
> > BUG=v8:6409
> > 
> > Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
> > Reviewed-on: https://chromium-review.googlesource.com/619153
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Marja Hölttä <marja@chromium.org>
> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#47501}
> 
> TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
> 
> Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6409
> Reviewed-on: https://chromium-review.googlesource.com/625998
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47506}

TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com

Change-Id: I68785c6be7686e874b3848103e3a34483eaeb519
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/625919Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47535}
      8bf15bf1
  41. 22 Aug, 2017 2 commits
  43. 17 Aug, 2017 3 commits
  45. 15 Aug, 2017 1 commit
  47. 11 Aug, 2017 2 commits
    • Ross McIlroy's avatar
      [Interpreter] Remove new.target from fixed frame slot. · c820b89b
      Ross McIlroy authored 
      Removes the new.target slot from the interpreter's fixed frame. Instead
adds a field to BytecodeArray to get the bytecode's incoming
new.target or generator object register. The InterpreterEntryTrampoline
then sets this register with the incoming new.target (or generator object)
when the function is called. This register can be directly the new.target
or generator object variable if they are LOCAL location, otherwise it is a
temporary register which is then moved to the variable's location during the
function prologue.

This fixes a hack in the deoptimizer where we would set the new.target fixed
slot to undefined in order to avoid extending it's lifetime through the
optimized code - now it's just a standard register and can be optimized away
as normal.

Bug=v8:6644

Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae
Reviewed-on: https://chromium-review.googlesource.com/608966
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47320}
      c820b89b
    • Ross McIlroy's avatar
      [fullcodegen] Delete FullCodegen. · 1458e8b0
      Ross McIlroy authored 
      Deletes the now unused Full-codegen compiler. Also removes some macro
assembler instructions which are no longer used.

Note: there is still additional cleanup work to do after this lands
(e.g., remove support for FCG frames support and FCG
debugger support, etc.), but this will be done in followup CLs to keep
this patch managable.

BUG=v8:6409

Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
Reviewed-on: https://chromium-review.googlesource.com/584773
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47307}
      1458e8b0
  49. 07 Aug, 2017 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Properly check new.target parameter in inlined Reflect.construct. · cb9402aa
      Benedikt Meurer authored 
      The ConstructFunctionForwardVarargs and ConstructForwardVarargs
builtins, which are used when inlining the Reflect.construct
builtin into TurboFan optimized code, didn't properly check the
new.target parameter whether it's a constructor.

Bug: chromium:752481
Change-Id: I9b8f8c429d6eaed0ff8d27fc3f6b52eb906766a2
Reviewed-on: https://chromium-review.googlesource.com/604187
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47206}
      cb9402aa
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · ee350c31
      Benedikt Meurer authored 
      Drop the deprecated CallConstructStub and remove the use of CallICStub
from fullcodegen, since that feedback is unused completely every since
Crankshaft got removed, thus we can safely unlink all the CallIC stuff
from fullcodegen nowadays, and completely nuke the CallICStub and the
CallICTrampolineStub now (we can also transitively nuke the unused
CreateAllocationSiteStub and CreateWeakCellStub).

Instead the CallIC logic is integrated into Ignition now, and part of
the bytecode handlers for [[Call]] and [[Construct]]. There's still some
follow-up cleanup with the way the Array constructor feedback is
integrated, but that's way easier now.

Bug: v8:5517, v8:6399, v8:6409, v8:6679
Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619
Reviewed-on: https://chromium-review.googlesource.com/603609
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47196}
      ee350c31