These are now direct dependencies in Node.js.
R=lushnikov@chromium.org
Change-Id: I01a68394e2e22a1024b6c21b8222ac8b113fc693
Reviewed-on: https://chromium-review.googlesource.com/1179143
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55573}
The typing rules for NumberMax and NumberMin didn't properly deal with
-0 up until now, leading to suboptimal typing, i.e. for a simple case
like
Math.max(Math.round(x), 1)
TurboFan was unable to figure out that the result is definitely going
to be a positive integer in the range [1,inf] or NaN (assuming that
NumberOrOddball feedback is used for the value x).
Bug: v8:8015
Change-Id: I06e14a9c9b0b813eb214ace7749fcc6ab36bb66a
Reviewed-on: https://chromium-review.googlesource.com/1199304
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55570}
Printing of both union and tuple types was broken such that the first
type was always skipped due to a bug.
Bug: v8:8015
Change-Id: I4bd215a9d8fa5bc7e017dd28e66512f4961228d1
Reviewed-on: https://chromium-review.googlesource.com/1199365
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55569}
This makes us spec compliant.
Bug: chromium:875643
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I489870495fe1d326991c99f0551fe3329268c984
Reviewed-on: https://chromium-review.googlesource.com/1199910
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55567}
Instead of creating the SFIs during bootstrapping and storing on the
context, this patch just creates the SFIs on demand.
This patch saves 8 words per context, and several words per bound
function by not storing the SFI.
The created bound JSFunction is cached on the instance anyway, so it's
totally fine to take a small hit when creating the bound JSFunction.
Previously in the JS implementation, the creation of a bound function
was even slower as it was a lazy function that would have to parsed,
compiled and executed. So this is a step up in terms up perf and
memory.
Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: If3b8461d00e5b37567b34b236d44e14576b630ff
Reviewed-on: https://chromium-review.googlesource.com/1200006
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55566}
Updates zx_vmar_*_old() callers back to the zx_vmar_*() equivalents,
which have a new parameter order.
Change-Id: I1662b4fbb866cef4eedc13e0db3e9389d4375d1e
Reviewed-on: https://chromium-review.googlesource.com/1199903
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55562}
This reorders arguments in preparation for removing ebx from its
calling convention (in a follow-up some args will be passed on the
stack).
Drive-by: Improve readability in the code handling different cases
(array,spread,...).
Bug: v8:6666
Change-Id: I0160f8efafd0fd0e841739578e01c32b38adb66e
Reviewed-on: https://chromium-review.googlesource.com/1196884
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55557}
We can safely lower ToNumeric(x) to ToNumber(x) as long as we can
guarantee that x is any primitive except BigInt (as ToNumeric would
return that unchanged while ToNumber will throw).
Bug: v8:8015
Change-Id: I66573cc204c7c919095ca7598a027fabef7d71a8
Reviewed-on: https://chromium-review.googlesource.com/1199665
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55556}
In preparation for kRootRegister support on ia32.
For both descriptors we simply shuffle registers around to remove ebx
from the calling convention.
Possible follow-up work: The ApiCallbackDescriptor could be simplified
by passing call_data (and the Undefined constant) on the stack. This
currently happens in the builtin body.
Drive-by: Minor refactoring in InterpreterPushArgsMode to deobfuscate
the different paths (spread/no-spread). Also use
{Push,Pop}ReturnAddress helpers.
Bug: v8:6666
Change-Id: I25fd738501fff71c038a0745cec04363f90df660
Reviewed-on: https://chromium-review.googlesource.com/1196552
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55554}
GetIdentityHashHelper function can return hash from GlobalDictionary,
but SetHashAndUpdateProperties crashes on DCHECK on attempt to set
this hash (it works when DCHECKs are disabled because SetHash is defined
on base class for NameDictionary and GlobalDictionary).
R=yangguo@chromium.org
Bug: none
Change-Id: I740fa6a3232f7db8e4396b9a5e4664b8ab81969a
Reviewed-on: https://chromium-review.googlesource.com/1198765
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55551}
DebugEvaluate contains code since 2009 that bypasses JSGlobalProxy and
returns JSGlobalObject when result of expression is global proxy.
This behavior may be dangerous:
- JSGlobalObject does not perform security checks,
- some parts of V8 code do not ready for JSGlobalObject, e.g.,
SetHashAndUpdateProperties function will crash on DCHECK if we will
try to store JSGlobalObject to map.
At the same time it looks like there is no any valid use case for it.
R=yangguo@chromium.org
Bug: none
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib0e35d5ae9ef47318c866e44c5c6856e34ed05a5
Reviewed-on: https://chromium-review.googlesource.com/1198764
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55550}
As noticed by jkummerow@ there's probably not really a point in
keeping two separate runtime functions that perform the same
operation, but one has a different fast-path (which is not
available to the other). So %KeyedGetProperty is now effectively
%GetProperty and used consistently as fallback from both the ICs
as well as other callers like the GetProperty builtin.
Bug: v8:8015
Change-Id: Ib46b13da739229e2eb820ecf87923ac99c6971d3
Reviewed-on: https://chromium-review.googlesource.com/1199105
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55547}
This CL fixes an issue where getters/setters would get called on a
prototype with the wrong receiver. This happens in the pre-processing
for Array.p.sort when values get copied down from the prototype chain.
R=jgruber@chromium.org
Bug: v8:7682
Change-Id: I0d8ff1dc721c33bd721aaca54ffd357b3d2a2096
Reviewed-on: https://chromium-review.googlesource.com/1198767
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55546}
This reverts commit 1c48d52bb1.
Reason for revert: Clusterfuzz found something.
Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}
TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1199303
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55544}
If profiling is done with --log-source-code profview will now display
a "View source" link for each function in the tree view. Clicking this
will show a new source viewer, with sampled lines highlighted. See the
associated bug for screenshots.
This patch also fixes a bug in the profiler where the source info of
only the first code object for each function would be logged, and
includes some refactoring.
Bug: v8:6240
Change-Id: Ib96a9cfc54543d0dc9bef4657cdeb96ce28b223c
Reviewed-on: https://chromium-review.googlesource.com/1194231
Commit-Queue: Bret Sepulveda <bsep@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55542}
The %GetPrototype runtime function is not used anymore. Also remove the
cctests that were introduced to guard the Crankshaft optimizations for
the %_GetPrototype intrinsic.
Bug: v8:8015
Change-Id: I4b848f2c8d67209dae002d260a26867299d6b4a5
Reviewed-on: https://chromium-review.googlesource.com/1199106
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55541}
In the KeyedLoadICGeneric case the engine previously immediately fell
back to the %KeyedGetProperty runtime function if the key was not a
Name or a valid array index. This turns out to be really slow if a
program passes for example objects as keys. Since we already have all
the logic in place to convert an arbitrary JavaScript value to a Name,
we can just call into ToName first and then operate on the result of
that, which is significantly faster since C++ usually doesn't need to
call back into JavaScript then to convert a JSReceiver into a Name.
This also changes the ToName builtin to use the existing builtin for
NonPrimitiveToPrimitive, which stays in JavaScript land completely.
Since there's not really a point in inlining ToName into the call
sites, the other uses were also changed to call the builtin instead,
which saves some space and might also help with instruction cache
utilization (especially when the ToName logic is more involved now).
This improves the performance on the microbenchmark
```js
const n = 1e7;
const obj = {};
const key = [1,2];
const start = Date.now();
for (let i = 0; i < n; ++i) {
if (obj[key] === undefined) obj[key] = key;
}
print(`time: ${Date.now() - start} ms.`);
```
by up to 36%. On the ARES-6 ML benchmark the steady state improves by up
to ~7% and the overall mean for ARES-6 ML improves by up to ~6%. Further
improvements might be possible here if the GetProperty builtin could be
made faster for common prototype lookups like Symbol.toPrimitive and the
"valueOf" and "toString" functions.
Bug: v8:6344, v8:6670
Change-Id: Ic3ac2bc4d4277836ef03039de4eda5c5f66a85da
Reviewed-on: https://chromium-review.googlesource.com/1199022
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55540}
Teach the GetProperty builtin how to perform [[Get]] on JSProxy
instances by calling into the dedicated ProxyGetProperty builtin
that we already use for the LOAD_IC / KEYED_LOAD_IC. This is
important when proxies are used in places were GetProperty builtin
is used like for example as iterables in for..of loops or in spreads.
On a simple micro-benchmark like the following
```js
const proxy = new Proxy([1, 2, 3], {
get(target, property) { return target[property]; }
});
const TESTS = [
function testForOfProxy() { for (const x of proxy) {} },
function testSpreadProxy() { return [...proxy]; }
];
function test(fn) {
var result;
for (var i = 0; i < 1e6; ++i) result = fn();
return result;
}
test(x => x);
for (var j = 0; j < TESTS.length; ++j) test(TESTS[j]);
for (var j = 0; j < TESTS.length; ++j) {
var startTime = Date.now();
test(TESTS[j]);
print(TESTS[j].name + ':', (Date.now() - startTime), 'ms.');
}
```
improves from around
testForOfProxy: 1672.6 ms.
testSpreadProxy: 1956.6 ms.
to
testForOfProxy: 408.4 ms.
testSpreadProxy: 530.8 ms.
on average, which corresponds to a 4-5x performance improvement, even
for small arrays. On the ARES-6 Air benchmark this completely eliminates
all calls to the %GetProperty runtime function, and thereby improves the
steady state mean by 2-3%.
Bug: v8:6344, v8:6557, v8:6559
Change-Id: Ifebdaff8f3ae5899a33ce408ecd54655247f3a02
Reviewed-on: https://chromium-review.googlesource.com/1199023
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55539}
Change-Id: I4b810b3684609f19cef3adf295ac104d00b9a4c3
Reviewed-on: https://chromium-review.googlesource.com/1194441
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55536}
- Cleans up existing code that tests for representations using a
bitmask.
- Bypass FP register allocation for sequences without FP vregs.
Change-Id: I5ff32e80e0c33848ba83ee17f786b01e37821aa2
Reviewed-on: https://chromium-review.googlesource.com/1195528
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55535}
This CL fixes a bug where the receiving instance was updated improperly
in the dispatch table(s) of an imported table.
BUG=chromium:875322
R=mstarzinger@chromium.org
Change-Id: Ib5af238a0847bf332a12863523e897f59f137c1d
Reviewed-on: https://chromium-review.googlesource.com/1196886
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55534}
We have an API (GetCodeRange) which gives the location of V8 code on the
heap, but builtin code no longer lives on the heap.
The upcoming work on the V8 stack unwinder requires the embedder to
provide the code ranges for both the heap and builtins, so this API will
be used there.
Bug: v8:8116
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I15e900716e68256b9732be0ea1a5cda24878eccf
Reviewed-on: https://chromium-review.googlesource.com/1196551
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55532}
This is a naive implementation of a class that manages regions
allocation/deallocation inside given range of addresses.
This code will be used in a follow-up CLs.
Bug: v8:8096
Change-Id: I7bea7051a1525cc7f87ba34d67b85b274c5de18a
Reviewed-on: https://chromium-review.googlesource.com/1127175
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55531}
This addresses a TODO in JSTypedLowering and generally makes the more
easier to follow since the methods deal only with one kind of Node now.
Bug: v8:8015
Change-Id: I8c3521b8d630dbe272264dc01e9ab3a5b0a8f682
Reviewed-on: https://chromium-review.googlesource.com/1196883
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55530}
This is a purely cosmetic change to make the Number constructor
in the JSCallReducer easier to read.
Bug: v8:7904, v8:8015
Change-Id: Id3248dcf9c4e8111bb4f0418bfa6993630df74bb
Reviewed-on: https://chromium-review.googlesource.com/1196432
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55528}
This CL removes a regression test that was intended to check that the
maximum call stack size was not exceeded when calling Array.p.sort.
As the new sorting algorithm (TimSort) does not work recursively, this
test is no longer really necessary. It is also rather slow and causes
issues on some bots, so we remove the test.
R=mslekova@chromium.org
Bug: v8:7783
Change-Id: I5bb9693ab825fe077776fd6825688545286285fd
Reviewed-on: https://chromium-review.googlesource.com/1196511
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55527}
This adds experimental support for an 'except_ref' value type for caught
exceptions as per the exception handling proposal. In the current for it
is only allowed to have such types in the stack or in a local, support
for having it as part of any signature was left out.
The default value for a local of type 'except_ref' is the 'ref_null'
value for now. Since this value cannot escape a wasm function, the
concrete value is not actually observable.
R=ahaas@chromium.org
TEST=unittests/LocalDeclDecoderTest.ExceptRef,mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: I7bd65274327a833262f8749cbe0e24e737f6e0c1
Reviewed-on: https://chromium-review.googlesource.com/1196510
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55526}
This CL fixes a bug if the second argument ('from') for lastIndexOf
changes the array when its converted to an integer.
R=jgruber@chromium.org
Bug: chromium:878845
Change-Id: I8759dd19381c63f0dde1d4c5abc1b6c7291c6048
Reviewed-on: https://chromium-review.googlesource.com/1196507
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55525}
