Skip to content

V
V8
Switch branch/tag
  1. 12 Oct, 2017 4 commits
    • Benedikt Meurer's avatar
      Revert "Reland^3 "[turbofan] eagerly prune None types and deadness from the graph"" · e29fd74c
      Benedikt Meurer authored 
      This reverts commit 4cf47645.

Reason for revert: Broken effect chains detected by Clusterfuzz. Playing it safe for the 63 branch.

Original change's description:
> Reland^3 "[turbofan] eagerly prune None types and deadness from the graph"
> 
> This fixes the issues 
> https://bugs.chromium.org/p/chromium/issues/detail?id=772873 
> and https://bugs.chromium.org/p/chromium/issues/detail?id=772872.
> 
> One problem was that mutating an effect node into Unreachable confused 
> the LoadElimination sidetables, so I just always create a new node now.
> 
> The other problem was that UpdateBlockControl() was executed after 
> UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input.
> So now I make sure that UpdateEffectPhi() is always executed last.
> 
> This is a reland of 6ddb5e7d
> Original change's description:
> > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph"
> > 
> > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the 
> > graph end. This fixes issues with later phases running DeadCodeElimination and
> > introducing new DeadValue nodes when processing uses of Unreachable.
> > 
> > This is a reland of 3c4bc27f
> > Original change's description:
> > > Reland "[turbofan] eagerly prune None types and deadness from the graph"
> > > 
> > > This is a reland of e1cdda25
> > > Original change's description:
> > > > [turbofan] eagerly prune None types and deadness from the graph
> > > > 
> > > > In addition to using the {Dead} node to prune dead control nodes and nodes that 
> > > > depend on them, we introduce a {DeadValue} node representing an impossible value 
> > > > that can occur at any position in the graph. The extended {DeadCodeElimination}
> > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> > > > the effect chain when possible. The remaining uses of {DeadValue} are handled
> > > > in {EffectControlLinearizer}, where we always have access to the effect chain.
> > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> > > > of a node with type {None} as dead.
> > > > 
> > > > Bug: chromium:741225
> > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> > > > Reviewed-on: https://chromium-review.googlesource.com/641250
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#48208}
> > > 
> > > Bug: chromium:741225
> > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
> > > Reviewed-on: https://chromium-review.googlesource.com/692034
> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#48232}
> > 
> > Bug: chromium:741225
> > Change-Id: I5702ec34856c075717162153adc765774453c45f
> > Reviewed-on: https://chromium-review.googlesource.com/702264
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48366}
> 
> Bug: chromium:741225
> Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f
> Reviewed-on: https://chromium-review.googlesource.com/709214
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48469}

TBR=jarin@chromium.org,tebbi@chromium.org

Change-Id: Icf6a6af4feaafd4bde28cb7b996735ff91bb3810
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:741225
Reviewed-on: https://chromium-review.googlesource.com/715096Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48482}
      e29fd74c
    • v8-autoroll's avatar
      Update V8 DEPS. · 840e92c5
      v8-autoroll authored 
      Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/adaf9e5..ddb142b

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a48a6af..072921b

Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/08cb956..21d33b1

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b3169f9..0c09c7a

Rolling v8/tools/luci-go: https://chromium.googlesource.com/chromium/src/tools/luci-go/+log/9f54aa9..45a8a51

TBR=machenbach@chromium.org,hablich@chromium.org

Change-Id: I7796e40539570a9eca5dbca27d4cb69dbe62e5b3
Reviewed-on: https://chromium-review.googlesource.com/714698Reviewed-by: 's avatarv8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48481}
      840e92c5
    • Jaroslav Sevcik's avatar
      Make sure the identity hash is uniform (at least in the lower bits). · a803fad0
      Jaroslav Sevcik authored 
      In the current implementation of hash code for objects (identity hash),
we do not bother to shift the hash when we retrieve it from the 
hash-length bitfield in a property array. (Even worse, we store shifted
value even if we do not have property array or inside dictionaries.)
That means that the hash-code for objects is always divisible by 1024.
Since our hash table uses a simple masking with (2^logsize - 1) to 
obtain the bucket, we get terrible hash collisions - essentially, our
hash table degenerates to a linked list for fewer than 1024 elements.

This CL always shifts the hash code so that the value in the lowest 
21 bits is uniformly distributed.

This results in big improvements on medium to large hash tables.
A program storing 1M elements into a WeakMap gets roughly
17x faster.  A program retrieving 1M elements from a Map 
improves even more dramatically (>100x).

const a = [];
for (let i = 0; i < 1e6; i++) a[i] = {};

const m = new Map();
console.time("Map.set");
for (let i = 0; i < 1e6; i++) {
  m.set(a[i], i);
}
console.timeEnd("Map.set");

console.time("Map.get");
let s = 0;
for (let i = 0; i < 1e6; i++) {
  s += m.get(a[i]);
}
console.timeEnd("Map.get");

const w = new WeakMap();
console.time("WeakMap.set");
for (let i = 0; i < 1e6; i++) {
  w.set(a[i], i);
}
console.timeEnd("WeakMap.set");

Before the fix:

Map.set: 157.575000
Map.get: 28333.182000
WeakMap.set: 6923.826000

After the fix:

Map.set: 178.382000
Map.get: 185.930000
WeakMap.set: 409.529000

Note that Map does not suffer from the hash collision on insertion because
it uses chaining (insertion into linked list is fast regardless of size!), and
we cleverly avoid lookup in the hash table on update if the key does not have 
identity hash yet. This is in contrast to the WeakMap, which uses 
open-addressing, and deals with collisions on insertion.

Bug: v8:6916
Change-Id: Ic5497bd4501e3b767b3f4acb7efb4784cbb3a2e4
Reviewed-on: https://chromium-review.googlesource.com/713616Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48480}
      a803fad0
    • Jakob Kummerow's avatar
      [bigint] Support BigInts in -,~,++,-- unary ops · e34debaf
      Jakob Kummerow authored 
      and add the implementations for BitwiseNot, Increment, Decrement.
This CL teaches the respective bytecode handlers about BigInts,
and collects kBigInt type feedback for them (which TF discards
for now, substituting "any").

Bug: v8:6791
Change-Id: I4e802b301b9702d8270bda400edd7e885e6b11b9
Reviewed-on: https://chromium-review.googlesource.com/706101
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48479}
      e34debaf
  3. 11 Oct, 2017 36 commits