R=mvstanton@chromium.org

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

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

R=mvstanton@chromium.org

Review URL: https://chromiumcodereview.appspot.com/82743003

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

R=bmeurer@chromium.org

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

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

Usage:
tools/merge-to-branch.sh -R 12345 12346

R=machenbach@chromium.org

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

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

R=svenpanne@chromium.org

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

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

A performance regression in array literal creation was caused by refactoring that eliminated a special fast case for shallow arrays. At the same time the general case got a bit slower. This CL restores most of the performance without coding the special fast case. The virtual dispatching is unnecessary because we know what we want to do at compile time. A flag was added to Runtime::CreateArrayLiteral. The flags delivers information about shallowness but also whether or not allocation mementos should be created. This is useful for crankshafted code.

BUG=v8:3008
LOG=Y
R=mstarzinger@chromium.org

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

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

BUG=
R=hpayer@chromium.org

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

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

R=verwaest@chromium.org

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

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

R=yangguo@chromium.org

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

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

R=bmeurer@chromium.org

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

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

R=bmeurer@chromium.org

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

Patch from Ben Noordhuis <ben@strongloop.com>.

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

In this change, the support comes in two flavours:

--perf_jit_prof - outputs the files in a new perf format that only works with a
patched perf tool (patch obtained from Stephane Eranian). Both 'perf report' and
'perf annotate' are supported (the file format also contains the machine code).

--perf_basic_prof - outputs the files in a format that the existing perf tool
can consume. Only 'perf report' is supported.

In both cases, we have to disable code compaction because the perf tool does not
understand code relocation. (We are told that code relocation should be
supported soon.)

Usage:

perf record -g d8 --perf_jit_prof --no_compact_code_space my.js
perf report

The change itself is straightforward - we simply listen to code events and
write an entry to a log file for every new piece of code.

I am not yet sure whether we should keep both versions or just one (and which
one). My hope is the reviewers can help here.

R=danno@chromium.org
BUG=

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

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

R=danno@chromium.org

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

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

Port r18025 (74fc739)

BUG=

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

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

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

Port r18024 (8956065)

BUG=

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

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

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

This commit fixes a lot of test failures that we saw earlier in the buildbots (http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20mips%20-%20sim/builds/3034/steps/Check/logs/stdio).

In some very rare cases the code age stub address can be 0xXXXX0000 and in this case the li maco instruction emits only 1 instruction (instead of the expected 2). Thus the code age sequence will be 6 instructions long instead of 7, which breaks the code aging feature. This change makes sure that li always emits 2 instructions and it also simplifies the code aging sequence.

Also fixes a small mistake in the simulator at the jalr instruction.

BUG=
R=gergely@homejinni.com

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

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

R=hpayer@chromium.org

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

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

BUG=
R=ulan@chromium.org

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

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

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

BUG=
R=ishell@chromium.org

Review URL: https://chromiumcodereview.appspot.com/80693002

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

R=ishell@chromium.org

Review URL: https://chromiumcodereview.appspot.com/78023002

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

BUG=none
R=svenpanne@chromium.org
LOG=y

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

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

The changes are (excluding presubmit.py) mechanical. I added the following
lines after the check and iterated the presubmit script until all errors
went away:

f = open(name, "w");
if contents.endswith('\n\n'):
  f.write(contents[0:-1])
else:
  f.write(contents + '\n')

R=jkummerow@chromium.org

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

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

BUG=
R=danno@chromium.org, jkummerow@chromium.org

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

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

R=verwaest@chromium.org
BUG=

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

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

It avoids having dead pointers in code from the time it was marked for deoptimization until it is deoptimized.

BUG=320532,v8:2996
TEST=mjsunit/regress/regress-320532.js
LOG=Y
R=danno@chromium.org

Review URL: https://chromiumcodereview.appspot.com/61213012

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

Also turn on deprecation warnings

BUG=v8:3023
R=svenpanne@chromium.org, dcarney@chromium.org
LOG=n

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

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

R=verwaest@chromium.org
BUG=

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

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

Also turn on deprecation warnings

BUG=v8:3023
R=svenpanne@chromium.org, dcarney@chromium.org
LOG=n

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

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

Also turn on depreaction warnings

BUG=v8:3023
R=svenpanne@chromium.org, dcarney@chromium.org
LOG=n

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

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

Also turn on deprecation warnings for samples

BUG=v8:3023
R=dcarney@chromium.org, svenpanne@chromium.org
LOG=n

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

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

R=jkummerow@chromium.org

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

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

For 31-bit smis, we don't need to explicitly check whether the
combined string length exceeds the max supported string length,
since the value must be converted to a smi at some point (i.e.
when it is stored into the string length field of the resulting
string), which will emit an overflow check.

For 32-bit smis, we insert an explicit check that the combined
string length does not exceed String::kMaxLength.

This also enables to get rid of the JoinContinuation() usage in
BuildUncheckedStringAdd().

BUG=v8:2990
LOG=n
R=mvstanton@chromium.org

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

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

Just ask the graph builder whether we are compiling a stub.

R=svenpanne@chromium.org

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

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

The main change is that a bit has been added to array buffers to
signal that the backing store has to be freed when the buffer dies.

BUG=316359
LOG=Y
R=yangguo@chromium.org

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

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

We turn the default for standalone builds on, however, I added overrides
to all targets to turn it locally off again. In follow up CLs, I'll
clean up one target at a time.

BUG=v8:3023
R=dcarney@chromium.org, machenbach@chromium.org
LOG=n

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

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

R=bmeurer@chromium.org

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

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

and preserve FP registers on NotifyStubFailure.

In debug mode, clobber FP registers on each runtime call to increase
chances of catching such bugs.

R=danno@chromium.org

Review URL: https://chromiumcodereview.appspot.com/78283002

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

R=danno@chromium.org

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

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

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

R=jkummerow@chromium.org

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

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