This enables linter checking for "readability/namespace" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1371083003
Cr-Commit-Position: refs/heads/master@{#31019}
Previously, the only optimized code path for Maps and Sets was for String keys.
This was achieved through an implementation of various complex operations
in Hydrogen. This approach was neither scalable nor forward-compatible.
This patch adds the necessary intrinsics to implement Maps and Sets almost entirely
in JS. The added intrinsics are:
%_FixedArrayGet
%_FixedArraySet
%_TheHole
%_JSCollectionGetTable
%_StringGetRawHashField
With these additions, as well as a few changes to what's exposed as runtime functions,
most of the C++ code backing Maps and Sets is gone (including both runtime code in
objects.cc and Crankshaft in hydrogen.cc).
Review URL: https://codereview.chromium.org/947683002
Cr-Commit-Position: refs/heads/master@{#27605}
OrderedHashTable is an insertion-ordered HashTable based on
Jason Orendorff's writeup of a data structure attributed to Tyler Close:
https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables
It is intended as the new backing store for JSSet/JSMap, as ES6 requires
insertion-order-based iteration. Note, however, that in the interest of
keeping the initial check-in small this patch does not yet include any
iteration support.
This change also doesn't yet touch any existing behavior, but in
a branch I've verified that these structures pass the existing
JSSet/JSMap mjsunit tests.
BUG=v8:1793
LOG=N
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/220293002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20522 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The algorithm puts elements into correct positions in multiple iterations.
On the first iteration it tries to put elements at entries specified by
their first hash probe. On the second iteration -- by the second
hash probe, and so on. Overall it does O(k*n) memory accesses, where
k is the maximum number of probes required for an element and n is the
capacity of the hash table. The expectation is that k will be small.
R=mstarzinger@chromium.org
Review URL: https://chromiumcodereview.appspot.com/23658031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16678 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I tried to limit the use of v8::Isolate::GetCurrent() and v8::internal::Isolate::Current() as much as possible, but sometimes this would have involved restructuring tests quite a bit, which is better left for a separate CL.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12716010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13953 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The flag passed to JSObject::GetIdentityHash() was not respected so far
and an indentity hash code was generated even when the flag requested
not to do so. This could lead to a rare corner cases (for which a test
case was added) where a GC request would have been dropped.
R=rossberg@chromium.org
TEST=cctest/test-dictionary
Review URL: http://codereview.chromium.org/8390047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9801 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
