Skip to content

V
V8
Switch branch/tag
  1. 31 Aug, 2018 3 commits
    • jgruber's avatar
      Refactor InterpreterPushArgsThenConstruct · 85cd0d87
      jgruber authored 
      This reorders arguments in preparation for removing ebx from its
calling convention (in a follow-up some args will be passed on the
stack).

Drive-by: Improve readability in the code handling different cases
(array,spread,...).

Bug: v8:6666
Change-Id: I0160f8efafd0fd0e841739578e01c32b38adb66e
Reviewed-on: https://chromium-review.googlesource.com/1196884Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55557}
      85cd0d87
    • Georg Neis's avatar
      Revert "[interpreter] Add bytecode for leading array spreads." · ef569028
      Georg Neis authored 
      This reverts commit 1c48d52b.

Reason for revert: Clusterfuzz found something.

Original change's description:
> [interpreter] Add bytecode for leading array spreads.
> 
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
> 
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
> 
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
> 
> Bug: v8:7980
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}

TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com

Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55544}
      ef569028
    • Benedikt Meurer's avatar
      [ic] Teach KeyedLoadICGeneric about ToName. · 923127f8
      Benedikt Meurer authored 
      In the KeyedLoadICGeneric case the engine previously immediately fell
back to the %KeyedGetProperty runtime function if the key was not a
Name or a valid array index. This turns out to be really slow if a
program passes for example objects as keys. Since we already have all
the logic in place to convert an arbitrary JavaScript value to a Name,
we can just call into ToName first and then operate on the result of
that, which is significantly faster since C++ usually doesn't need to
call back into JavaScript then to convert a JSReceiver into a Name.

This also changes the ToName builtin to use the existing builtin for
NonPrimitiveToPrimitive, which stays in JavaScript land completely.
Since there's not really a point in inlining ToName into the call
sites, the other uses were also changed to call the builtin instead,
which saves some space and might also help with instruction cache
utilization (especially when the ToName logic is more involved now).

This improves the performance on the microbenchmark

```js
const n = 1e7;
const obj = {};
const key = [1,2];

const start = Date.now();
for (let i = 0; i < n; ++i) {
  if (obj[key] === undefined) obj[key] = key;
}
print(`time: ${Date.now() - start} ms.`);
```

by up to 36%. On the ARES-6 ML benchmark the steady state improves by up
to ~7% and the overall mean for ARES-6 ML improves by up to ~6%. Further
improvements might be possible here if the GetProperty builtin could be
made faster for common prototype lookups like Symbol.toPrimitive and the
"valueOf" and "toString" functions.

Bug: v8:6344, v8:6670
Change-Id: Ic3ac2bc4d4277836ef03039de4eda5c5f66a85da
Reviewed-on: https://chromium-review.googlesource.com/1199022
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55540}
      923127f8
  3. 30 Aug, 2018 2 commits
    • Hai Dang's avatar
      [interpreter] Add bytecode for leading array spreads. · 1c48d52b
      Hai Dang authored 
      This CL improves the performance of creating [...a, b] or [...a].
If the array literal has a leading spread, this CL emits the bytecode
[CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
is implemented by [IterableToListDefault] builtin to create the initial
array for the leading spread. IterableToListDefault has a fast path to
clone efficiently if the spread is an actual array.

The bytecode generated is now shorter. Bytecode generation is refactored
into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
from this optimization also.
For now, turbofan also lowers the bytecode to the builtin.

The idiomatic use of [...a] to clone the array a now performs better
than a simple for-loop, but still does not match the performance of slice.

Bug: v8:7980

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#55520}
      1c48d52b
    • Dan Elphick's avatar
      [embed handlers] Make bytecode handlers isolate independent · c68644bb
      Dan Elphick authored 
      Use BuiltinAssemblerOptions to generate AssemblerOptions when generating
the bytecode handlers (assuming v8_enable_embedded_bytecode_handlers is
on).

Mark all but InvokeIntrinsic, InvokeIntrinsicWide,
InvokeIntrinsicExtraWide, TestIn, TestInWide, TestInExtraWide and
TestTypeOf as isolate-independent. The excluded handlers create jump
tables which have absolute addresses.

Bug: v8:8068
Change-Id: Ia29e9c737ec345193e24fc2aa3684daefb113a9a
Reviewed-on: https://chromium-review.googlesource.com/1195508Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55514}
      c68644bb
  5. 28 Aug, 2018 1 commit
  7. 24 Aug, 2018 1 commit
  9. 23 Aug, 2018 1 commit
  11. 21 Aug, 2018 2 commits
  13. 13 Aug, 2018 1 commit
  15. 10 Aug, 2018 1 commit
  17. 09 Aug, 2018 2 commits
  19. 08 Aug, 2018 1 commit
  21. 07 Aug, 2018 2 commits
  23. 25 Jul, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] fix ClusterFuzz regressions (and remaining nits) in CloneObject · d6efcbf0
      Caitlin Potter authored 
      Includes fixes for several ClusterFuzz regressions:

1) fix an invalid Handle-cast in ic.cc (chromium:866282)

2) fix for improper accounting of used/unused inobject
fields, found by clusterfuzz (chromium:866357).

3) fix number of control outputs for the JSCloneObject
operator to be used by IfSuccess and IfException nodes (chromium:866727).

4) fix property constness in out-of-object properties of fast-cloned
object to be compatible with DCHECKs in StoreIC (chromium:866861).

Also includes the fixups missing from the initial commit, and
regression tests

BUG=v8:7611, chromium:866282, chromium:866357, chromium:866727, chromium:866861
R=jkummerow@chromium.org, mvstanton@chromium.org
TBR=rmcilroy@chromium.org

Change-Id: I77220308482f16db2893c0dcebec36530d0f5540
Reviewed-on: https://chromium-review.googlesource.com/1146297
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54706}
      d6efcbf0
  25. 23 Jul, 2018 1 commit
  27. 20 Jul, 2018 4 commits
  29. 12 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [cleanup] Remove Isolate parameter from object print · 13b899a5
      Leszek Swirski authored 
      With ReadOnlyRoots and GetIsolate on JSReceiver, we can remove almost
every isolate parameter from <Object>::Print. The remaining ones, like
Map, are special-caseable for read-only maps, and as a result we can
remove isolate parameters from <Object>::Print entirely.

This patch also opportunistically cleans up a few places where isolates
were only needed for Object::Print, such as TransitionAccessors and
DescriptorArrays.

TBR=yangguo@chromium.org,mstarzinger@chromium.org

Bug: v8:7786
Change-Id: Id44bd53b9893e679eea5f37b9548257595a1bfd9
Reviewed-on: https://chromium-review.googlesource.com/1133385Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54401}
      13b899a5
  31. 06 Jul, 2018 1 commit
  33. 05 Jul, 2018 1 commit
  35. 04 Jul, 2018 2 commits
  37. 02 Jul, 2018 1 commit
  39. 26 Jun, 2018 1 commit
  41. 22 Jun, 2018 1 commit
  43. 21 Jun, 2018 1 commit
  45. 20 Jun, 2018 1 commit
  47. 18 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Make CallInterfaceDescriptor isolate-independent · 3cb376dc
      Clemens Hammacher authored 
      Currently each isolate stores its own array of
{CallInterfaceDescriptorData}. This array has size 173, and each entry
has 40 bytes. That's already 7kB per isolate.
Additionally, each {CallInterfaceDescriptorData} allocates two
heap-allocated arrays, which probably add up to more than the static
size of the {CallInterfaceDescriptorData}. Note that all the
{CallInterfaceDescriptorData} instances are initialized eagerly on
isolate creation.

Since {CallInterfaceDescriptor} is totally isolate independent itself,
this CL refactors the current design to avoid a copy of them per
isolate, and instead shares them process-wide. Still, we need to free
the allocated heap arrays when the last isolate dies to avoid leaks.
This can probably be refactored later by statically initializing more
and avoiding the heap allocations all together.

This refactoring will also allow us to use {CallInterfaceDescriptor}s
from wasm background compilation threads, which are not bound to any
isolate.

R=mstarzinger@chromium.org, titzer@chromium.org

Bug: v8:6600
Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
Reviewed-on: https://chromium-review.googlesource.com/1100879
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53803}
      3cb376dc
    • Leszek Swirski's avatar
      [GetIsolate] Return raw object for bytecode constants · f67e424d
      Leszek Swirski authored 
      Return the raw Object* when accessing the constant pool of bytecode
with the bytecode array accessor, to avoid needing an isolate there.
If the returned value needs to be a handle, we create the handle
later.

Bug: v8:7786
Change-Id: Ifeac2a06f0383230bf7e9bfc1b751d9750ecfb51
Reviewed-on: https://chromium-review.googlesource.com/1102334
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53784}
      f67e424d
  49. 14 Jun, 2018 3 commits
    • jgruber's avatar
      Fix stack check pattern matching for CSA code · 9ff644ae
      jgruber authored 
      The stack check instruction sequence is pattern-matched in
instruction-selector-{ia32,x64}.cc and replaced with its own specialized
opcode, for which we later generate an efficient stack check in a single
instruction.

But this pattern matching has never worked for CSA-generated code. The
matcher expected LoadStackPointer in the right operand and the external
reference load in the left operand. CSA generated exactly vice-versa.

This CL does a few things; it
1. reverts the recent change to load the
limit from smi roots:

Revert "[csa] Load the stack limit from smi roots"
This reverts commit 507c29c9.

2. tweaks the CSA instruction sequence to output what the matcher
expects.
3. refactors stack check matching into a new StackCheckMatcher class.
4. typifies CSA::PerformStackCheck as a drive-by.

Bug: v8:6666,v8:7844
Change-Id: I9bb879ac10bfe7187750c5f9e7834dc4accf28b5
Reviewed-on: https://chromium-review.googlesource.com/1099068Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53737}
      9ff644ae
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored 
      This is a reland of 0909dbe3.
Added missing V8_EXPORT_PRIVATE to AndroidLogStream.

TBR=mstarzinger@chromium.org

Original change's description:
> Introduce StdoutStream which prints to Android log or stdout
>
> The often used construct {OFStream(stdout)} does not work on Android.
> This CL introduces an {StdoutStream} which behaves exactly like
> {OFStream(stdout)} on non-android platforms, and redirects to the
> Android log on appropriate systems and configurations.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:7820
> Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
> Reviewed-on: https://chromium-review.googlesource.com/1088911
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53692}

Bug: v8:7820
Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257
    • Michael Achenbach's avatar
      Revert "Introduce StdoutStream which prints to Android log or stdout" · d2e1620c
      Michael Achenbach authored 
      This reverts commit 0909dbe3.

Reason for revert: Blocks roll:
https://chromium-review.googlesource.com/c/chromium/src/+/1099143

Original change's description:
> Introduce StdoutStream which prints to Android log or stdout
> 
> The often used construct {OFStream(stdout)} does not work on Android.
> This CL introduces an {StdoutStream} which behaves exactly like
> {OFStream(stdout)} on non-android platforms, and redirects to the
> Android log on appropriate systems and configurations.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: v8:7820
> Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
> Reviewed-on: https://chromium-review.googlesource.com/1088911
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53692}

TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org

Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7820
Reviewed-on: https://chromium-review.googlesource.com/1100635Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53725}
      d2e1620c
  51. 13 Jun, 2018 1 commit
  53. 12 Jun, 2018 1 commit