Skip to content

V
V8
Switch branch/tag
  1. 31 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [ic] Add OOB support to KeyedLoadIC. · 6dc35ab4
      Benedikt Meurer authored 
      This adds support to the KeyedLoadIC to ignore out of bounds accesses
for Strings and return undefined instead. We add a dedicated bit to the
Smi handler to encode the OOB state and have TurboFan generate appropriate
code for that case as well. This is mostly useful when programs
accidentially access past the length of a string, which was observed and
fixed for example in Babel recently, see

  https://github.com/babel/babel/pull/6589

for details. The idea is to also extend this mechanism to Arrays and
maybe other receivers, as reading beyond the length is also often used
in jQuery and other popular libraries.

Note that this is considered a mitigation for a performance cliff and
not a general optimization of OOB accesses. These should still be
avoided and handled properly instead.

This seems to further improve the babel test on the web-tooling-benchmark
by around 1%, because the OOB access no longer turns the otherwise
MONOMORPHIC access into MEGAMORPHIC state.

Bug: v8:6936, v8:7014
Change-Id: I9df03304e056d7001a65da8e9621119f8e9bb55b
Reviewed-on: https://chromium-review.googlesource.com/744022
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49049}
      6dc35ab4
  3. 30 Oct, 2017 4 commits
  5. 27 Oct, 2017 1 commit
  7. 26 Oct, 2017 4 commits
  9. 25 Oct, 2017 4 commits
  11. 24 Oct, 2017 4 commits
  13. 20 Oct, 2017 4 commits
  15. 19 Oct, 2017 1 commit
  17. 16 Oct, 2017 2 commits
  19. 13 Oct, 2017 4 commits
  21. 12 Oct, 2017 3 commits
    • Igor Sheludko's avatar
      [ic] Introduce proper slow stub for StoreGlobalIC. · 3384a793
      Igor Sheludko authored 
      Bug: chromium:768875
Change-Id: Ib5b324e90bea846e6cca419f81bf46bd293e83b4
Reviewed-on: https://chromium-review.googlesource.com/715802Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48503}
      3384a793
    • Igor Sheludko's avatar
      [ic] Do access checks when storing via JSGlobalProxy. · 5ea95feb
      Igor Sheludko authored 
      Bug: chromium:764219
Change-Id: I99d1192c5c0f2b8bf47e0f193a0c4d9c00477466
Reviewed-on: https://chromium-review.googlesource.com/712454
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48492}
      5ea95feb
    • 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
  23. 06 Oct, 2017 1 commit
  25. 03 Oct, 2017 1 commit
  27. 02 Oct, 2017 2 commits
    • Benedikt Meurer's avatar
      [ic] Properly handle polymorphic symbol accesses. · 08db4d76
      Benedikt Meurer authored 
      Until now keyed accesses to properties with string or symbol keys were
only optimized properly while the IC was monomorphic and would go
megamorphic as soon as there's another receiver map, even if the name
was still the same (i.e. the same symbol or internalized string). This
was a weird performance-cliff, that'll hurt modern code especially
because for symbols you can only access them via keyed loads and stores.

This CL fixes the state machine inside the ICs to properly transition to
POLYMORPHIC state (and stay there) as long as the new name matches the
previously recorded name. The FeedbackVector and TurboFan were already
able to deal with this and didn't need any updates.

On the micro-benchmark from the tracking bug we go from

  testStringMonomorphic: 429 ms.
  testSymbolMonomorphic: 431 ms.
  testStringPolymorphic: 429 ms.
  testSymbolPolymorphic: 5621 ms.

to

  testStringMonomorphic: 429 ms.
  testSymbolMonomorphic: 429 ms.
  testStringPolymorphic: 429 ms.
  testSymbolPolymorphic: 430 ms.

effectively eliminating the overhead for symbols completely, and
yielding a 13.5x performance boost.

This also seems to yield a 1% improvement on the ARES6 ML benchmark,
because it eliminates the KEYED_LOAD_ICs for the Symbol.species lookups.

Bug: v8:6367, v8:6278, v8:6344
Change-Id: I879fe56387b4c56203c1ad8ef8cafb6cc4c32897
Reviewed-on: https://chromium-review.googlesource.com/695108Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48261}
      08db4d76
    • Daniel Clifford's avatar
      Introduce protector cell helper functions in CSA · 05437821
      Daniel Clifford authored 
      Change-Id: Iac4a95a0c094472d887d89bbf5d6189988c56f7c
Reviewed-on: https://chromium-review.googlesource.com/692016
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48253}
      05437821
  29. 29 Sep, 2017 3 commits
  31. 28 Sep, 2017 1 commit