The only ways we use this class require it, as multiple isolates can race
to initialize data structures. This showed up as intermittant failures on
nosnap build bots.

R=hpayer@chromium.org

Review URL: https://codereview.chromium.org/238973004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20794 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=ishell@chromium.org

Review URL: https://codereview.chromium.org/239203002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20793 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=ishell@chromium.org

Review URL: https://codereview.chromium.org/236063016

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20792 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=ishell@chromium.org

Review URL: https://codereview.chromium.org/238543005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20791 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=363956
TEST=mjsunit/regress/regress-363956
LOG=y
R=jarin@chromium.org

Review URL: https://codereview.chromium.org/239623005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20788 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This makes Chrome's --single-process work again, but the real solution
is to pass an Isolate explicitly and fixing things on the Chrome side
=> follow-up CLs.

R=ulan@chromium.org

Review URL: https://codereview.chromium.org/239513006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20787 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/236303015

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=dslomov@chromium.org

Review URL: https://codereview.chromium.org/239143003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20785 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/232673003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20784 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Port r20751 (18578019)

BUG=
R=plind44@gmail.com

Review URL: https://codereview.chromium.org/239803004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20783 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reverts commit https://code.google.com/p/v8/source/detail?r=20781.

It broke the Win32 builders.

TBR=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/239163012

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20782 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.

Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.

The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.

When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.

When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.

At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.

BUG=1793,2323
LOG=Y
R=adamk@chromium.org, mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/236143002

Patch from Erik Arvidsson <arv@chromium.org>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Important notices:

- The snapshot cannot be created for big-endian target in cross-compilation
  environment on little-endian host using simulator.

- In order to have i18n support working on big-endian target, the icudt46b.dat and
  icudt46b_dat.S files should be generated and upstreamed to ICU repo.

- The mjsunit 'nans' test is endian dependent, it is skipped for mips target.

- The zlib and Mandreel from Octane 2.0 benchmark are endian dependent due to
  use of typed arrays.

TEST=
BUG=
R=jkummerow@chromium.org, plind44@gmail.com

Review URL: https://codereview.chromium.org/228943009

Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20778 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

V8_Fatal no longer tries to print a js stack, so we don't need those
scopes

BUG=none
R=yangguo@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/239293002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20777 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Motivation is that x64 nosnapshot builds need a 129 byte delta at the moment.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/237673007

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20776 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reverts commit r20772.

TBR=jarin@chromium.org

Review URL: https://codereview.chromium.org/239273002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20775 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Port r20746 (09f9176)

Original commit message:
This is an initial step towards tracking the exact types instead of just
the representations of fields. It adds support to track up to one map of
heap object field values, eliminating various map checks on values
loaded from such fields, at the cost of making stores to such fields
slightly more expensive.

Issues with transitioning stores and fast object literals in Crankshaft
fixed.

TEST=mjsunit/field-type-tracking
BUG=
R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/238943002

Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20774 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/239133002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20773 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/239113002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20772 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This fixes accesses in ARM and ARM64; the field is a bool, with size 1,
but we were accessing it with pointer-sized loads and stores.

BUG=
R=ulan@chromium.org

Review URL: https://codereview.chromium.org/230553004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20771 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/239173002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20770 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/238113003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20769 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=ishell@chromium.org

Review URL: https://codereview.chromium.org/238273005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20768 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=dcarney@chromium.org, yangguo@chromium.org

Review URL: https://codereview.chromium.org/231973004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20767 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-builtinbust-5

Review URL: https://codereview.chromium.org/239033002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20766 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=ulan@chromium.org

Review URL: https://codereview.chromium.org/238583004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20765 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=jarin@chromium.org

Review URL: https://codereview.chromium.org/238993002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/238983002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20763 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Function allocators, Heap::ReinitializeJSGlobalProxy() and Heap::ReinitializeJSReceiver() handlified. Factory::New<>() added.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/237093006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20762 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=dslomov@chromium.org

Review URL: https://codereview.chromium.org/238543004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20761 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/238273006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20760 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=359977
LOG=y
R=dcarney@chromium.org

Review URL: https://codereview.chromium.org/238773003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20759 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/238933002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20758 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/238713003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20757 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=ishell@chromium.org

Review URL: https://codereview.chromium.org/236193014

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20756 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Setting the FPSCR flags is expensive on some CPUs. Get rid of repeated
setting of the FPSCR by relying on the correct default flags being set
when doing uint8 clamping. Also use vcvt_u32_f64 instead of vcvt_s32_f64,
which enables removing the check against zero (vcvt_u32_f64 will clamp to
zero).

To be on the safe side, add asserts to check that the VFP rounding mode
flags are set to default as expected.

This increases performance of a hot loop repeatedly setting
Uint8ClampedArray values on some CPUs by as much as a factor of 12.

BUG=v8:3253
LOG=N
R=jacob.bramley@arm.com, rmcilroy@chromium.org, ulan@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=20676

Review URL: https://codereview.chromium.org/230473005

Patch from Olli Etuaho <oetuaho@nvidia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20755 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=ishell@chromium.org

Review URL: https://codereview.chromium.org/238683004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20754 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=svenpanne@chromium.org

BUG=

Review URL: https://codereview.chromium.org/238843002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20753 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

It was a pretty monstrous 500 line function.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/237243003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20752 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=353058
LOG=N
TEST=mjsunit/regress/regress-353058
R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/236633006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20751 ce2b1a6d-e550-0410-aec6-3dcde31c8c00