This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Committed: https://crrev.com/e5ed3bee99807c502fa7d7a367ec401e16d3f773
Cr-Commit-Position: refs/heads/master@{#29689}
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29712}
Calling quit() from d8 will call exit(), which will run static destructors. If
context_mutex_ is statically allocated, pthread_mutex_destroy will be called.
When running d8 in "isolates" mode, another thread may be running. If it calls
CreateEvaluationContext, it will lock the context_mutex_. If the mutex is
destroyed while it is locked, it will return an error.
This CL changes the Mutex to a LazyMutex, which will leak instead of being
destroyed.
BUG=v8:4279
R=jarin@chromium.orgR=machenbach@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1240553003
Cr-Commit-Position: refs/heads/master@{#29709}
This makes the implicit initializing assignment to 'this' performed
after a super constructor call explicit in the AST. It removes the
need to handle the special case where a CallExpression behaves like a
AssignmentExpression from various AstVisitor implementations.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1226123010
Cr-Commit-Position: refs/heads/master@{#29705}
Port 1d9d895754
Original commit message:
This changes the calling convention of the CallConstructStub to take
the original constructor (i.e. new.target in JS-speak) in a register
instead of magically via the operand stack. For optimizing compilers
the operand stack doesn't exist, hence cannot be peeked into.
R=mstarzinger@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1230103004
Cr-Commit-Position: refs/heads/master@{#29702}
This helps reasoning about setting break points. Functions that
have debug info is also guaranteed to be able to set break points.
R=ulan@chromium.org
BUG=v8:4132
LOG=N
Review URL: https://codereview.chromium.org/1227213003
Cr-Commit-Position: refs/heads/master@{#29698}
original commit message:
This changes the calling convention of the CallConstructStub to take
the original constructor (i.e. new.target in JS-speak) in a register
instead of magically via the operand stack. For optimizing compilers
the operand stack doesn't exist, hence cannot be peeked into.
BUG=
Review URL: https://codereview.chromium.org/1235273003
Cr-Commit-Position: refs/heads/master@{#29695}
port fc9c5275c3 (r29672).
original commit message:
Debugger: use debug break slots to break at function exit.
By not having to patch the return sequence (we patch the debug
break slot right before it), we don't overwrite it and therefore
don't have to keep the original copy of the code around.
BUG=
Review URL: https://codereview.chromium.org/1236023007
Cr-Commit-Position: refs/heads/master@{#29694}
Improved checking target ranges for J and JAL instructions.
Adapted disassembler test for J and JAL instructions.
TEST=cctest/test-disasm-mips[64]
BUG=
Review URL: https://codereview.chromium.org/1237083003
Cr-Commit-Position: refs/heads/master@{#29693}
These were added when I thought they would be useful in Blink, but as
it turned out they were not. They could likely be deleted immediately,
but to play it safe I'll go through the usual deprecation process.
Review URL: https://codereview.chromium.org/1236263004
Cr-Commit-Position: refs/heads/master@{#29690}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29689}
For unclear and probably accidental reasons the Windows 10 SDK
renamed some _Interlocked* functions to _InlineInterlocked. This
leads to these errors:
runtime-atomics.cc(159): error C3861: '_InterlockedExchange64': identifier not found
runtime-atomics.cc(159): error C3861: '_InterlockedExchangeAdd64': identifier not found
runtime-atomics.cc(159): error C3861: '_InterlockedAnd64': identifier not found
runtime-atomics.cc(159): error C3861: '_InterlockedOr64': identifier not found
runtime-atomics.cc(159): error C3861: '_InterlockedXor64': identifier not found
Fixing this requires either adding defines to map these five _Interlocked*
functions to _InlineInterlocked*, or else changing to using the
non-underscore versions. It appears that using the non-underscore versions
is preferable so I went that way. This also requires adding three new
defines because there is a huge lack of consistency, probably due to these
macros being defined sometimes in <intrin.h> and sometimes in <winnt.h>
All five of the renamed 64-bit functions were manually checked to ensure
that the change to the non-underscore versions would make no differences -
the inline functions that they map to were identical. Other functions were
spot-checked.
Also, the 'volatile' qualifiers were removed. Volatile has no no useful
meaning for multi-threaded programming. It only exists in the Interlocked*
prototypes to *allow* volatile variables to be passed. Since this is a bad
habit to encourage there is no reason for us to permit it, and we can
still call the Microsoft functions (T* converts to volatile T*, just not
vice-versa).
The updated code builds with the Windows 8.1 SDK and with the Windows 10 SDK.
R=jarin@chromium.org
LOG=Y
BUG=440500,491424
Review URL: https://codereview.chromium.org/1228063005
Cr-Commit-Position: refs/heads/master@{#29687}
where bound functions started overriding the "name" accessor property with a data property. The bootstrapper must be kept in sync to avoid polymorphism.
BUG=chromium:509983
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1238903002
Cr-Commit-Position: refs/heads/master@{#29685}
During parsing, we now keep track of the first spread seen in an array
literal (if any), and make use of that information when creating the
FixedArray backing store representing the constant elements for array
literal materialization.
The old code tried to do this by setting the generated JSArray's length
in ArrayLiteral::BuildConstantElements(), but that Array length is never
read by the rest of the literal materialization code (it always uses
the length of the FixedArray backing store).
BUG=v8:4298
LOG=n
Review URL: https://codereview.chromium.org/1225223004
Cr-Commit-Position: refs/heads/master@{#29684}
This changes the calling convention of the CallConstructStub to take
the original constructor (i.e. new.target in JS-speak) in a register
instead of magically via the operand stack. For optimizing compilers
the operand stack doesn't exist, hence cannot be peeked into.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1237813002
Cr-Commit-Position: refs/heads/master@{#29681}
By not having to patch the return sequence (we patch the debug
break slot right before it), we don't overwrite it and therefore
don't have to keep the original copy of the code around.
R=ulan@chromium.org
BUG=v8:4269
LOG=N
Review URL: https://codereview.chromium.org/1234833003
Cr-Commit-Position: refs/heads/master@{#29672}
A sloppy mode eval call that establishes strict mode will leak that strictness
into the sloppy surrounding scope on recompile. This changes the structure
of the type feedback vector for the function and crashes follow.
The fix is straightforward.
BUG=491536, 503565
LOG=N
Review URL: https://codereview.chromium.org/1231343003
Cr-Commit-Position: refs/heads/master@{#29671}
This patch removes the MathMax call from String.prototype.includes
in order to improve performance. With some quick and dirty benchmarking,
(test case courtesy of the node folks) a sizable performance gain is visible:
d8> function testIndexOf() { var stringArray = [ 'hello', 'world', '123', 'abc' ]; return stringArray.some(function(val, idx, arr) { return val.indexOf('world') !== -1 })}
d8> function testIncludes() { var stringArray = [ 'hello', 'world', '123', 'abc' ]; return stringArray.some(function(val, idx, arr) { return val.includes('world') })}
d8> function testTime(fn) { var before = Date.now(); fn(); return Date.now() - before; }
d8> testTime(function() { for (var i = 0; i < 10000000; i++) { testIncludes() } })
2244
d8> testTime(function() { for (var i = 0; i < 10000000; i++) { testIndexOf() } })
2212
Compare that to before the test, when the performance difference was much larger:
d8> testTime(function() { for (var i = 0; i < 10000000; i++) { testIndexOf() } })
2223
d8> testTime(function() { for (var i = 0; i < 10000000; i++) { testIncludes() } })
2650
In my runs, performance of both functions drifts up and down, but running them in quick
succession back and forth shows a roughly consistent delta of about this magnitude.
String.prototype.includes is still slightly (maybe 5%) slower than String.prototype.indexOf,
but the effect is significantly reduced.
R=adamk
BUG=v8:3807
LOG=Y
Review URL: https://codereview.chromium.org/1231673008
Cr-Commit-Position: refs/heads/master@{#29665}
