Bisected to 11d80c95caac115e3c6daf8545b2a7e04a8f1c3d
"[array] Fast allocation in Array.p.map and Array.p.filter"
Landed in 60.0.3098.0 via r471390

Simplified test.html is attached.
Expected: 'GOOD' and two similar durations are displayed around 100ms
Observed: 'BAD' and vastly different durations like 100ms and 900ms

Note, make sure to test in 64 bit builds as 32-bit builds have a different threshold.

Deleted: test.html 421 bytes

test.html 421 bytes View Download

Able to reproduce the issue on Mac OS 10.13.6, Ubuntu 17.10 and Windows 10 (using the file in comment #1).As per commen1, assigning the issue to jgruber@ and below is the bisect information.

Bisect Information:
==============
Good Build:60.0.3097.0
Bad Build: 60.0.3098.0.

Changelog URL:
https://chromium.googlesource.com/v8/v8/+/11d80c95caac115e3c6daf8545b2a7e04a8f1c3d

Review-URL:https://codereview.chromium.org/2874833004

@jgruber: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks.!

Just confirming the perf cliff still exists on tot, haven't investigated further yet (setting a reminder). cc danno and mvstanton fyi.  Simple d8 repro:

function run(limit) {
  var a = new Array(limit).fill(0);
  var t0 = Date.now();
  for (var i = 0; i < 100; i++) {
    a.map(el => el * 100);
  }
  return Date.now() - t0;
}

var t1 = run(63384);
var t2 = run(63385);

print(t1);
print(t2);

The NextAction date has arrived: 2018-10-15

The limit we're hitting here is JSArray::kInitialMaxFastElementArray. With a capacity of 63385, the new array is too large to go into new space. 

This forces a full bailout to the slow generic path of the algorithm. I don't really see an obvious reason why this should be necessary. We can't skip write barriers anyway due to all the interleaved calls to JS. 

A 'slow' allocation in LO space should be able to stay on the fast path.

More complicated than I thought. For LO allocations we can't fold the JSArray + elements allocation into one, since LO space expects only one object per page.

I have a WIP CL that avoids this slow path (times t1 and t2 from #5 are now on par), but it still needs a bit of work before it can land.

Here's a first draft: https://chromium-review.googlesource.com/c/v8/v8/+/1301483

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/9eca2d3c378898533d9192ce3bb988f7bf2c3972

commit 9eca2d3c378898533d9192ce3bb988f7bf2c3972
Author: Jakob Gruber <jgruber@chromium.org>
Date: Tue Oct 30 13:30:56 2018

[array] Keep large array allocations on the fast path

Until this CL, CSA array allocation methods only handled arrays that
could fit into new space. This behavior was preserved in a bunch
of related builtins (e.g. Array.p.map), which completely bailed out to
the slow path if larger allocations were required.

This CL adds large object space handling to array allocation functions,
which means that callers can use the more permissive kMaxFastArrayLength
boundary instead of kInitialMaxFastElementsArray.

Bug:  chromium:890599 
Change-Id: Idabb0ef232c2896cd453e2ae10b479bf24cbb1c1
Reviewed-on: https://chromium-review.googlesource.com/c/1301483
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57124}
[modify] https://crrev.com/9eca2d3c378898533d9192ce3bb988f7bf2c3972/src/builtins/builtins-array-gen.cc
[modify] https://crrev.com/9eca2d3c378898533d9192ce3bb988f7bf2c3972/src/code-stub-assembler.cc
[modify] https://crrev.com/9eca2d3c378898533d9192ce3bb988f7bf2c3972/src/code-stub-assembler.h

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/5af64b6d7be4a08781563397db27360749186928

commit 5af64b6d7be4a08781563397db27360749186928
Author: Jakob Gruber <jgruber@chromium.org>
Date: Thu Nov 08 07:48:58 2018

[csa] Fully initialize elements for large JSArray allocations

This fixes an issue introduced in https://crrev.com/c/1301483.

The JSArray allocation could trigger GC and thus elements must be
fully initialized.

Bug:  v8:8429 , chromium:890599 
Change-Id: I7bfa1728c1dde7fc880063e095413163b13be2d5
Reviewed-on: https://chromium-review.googlesource.com/c/1322955
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57342}
[modify] https://crrev.com/5af64b6d7be4a08781563397db27360749186928/src/code-stub-assembler.cc