Bug 56823 – REGRESSION: Allocation of memory is slow when building a 2GB tree

• Component: JavaScriptCore
• Status: ASSIGNED

[Alan Tam]

1. Open the attached html using webkit r78249 or later.

Try the same for:
* Safari 5.0
* WebKit trunk r78794 or before
* Any version of Chrome

Notice how it is 10x slower than all others, where a pass (after the first dozen passes) takes >1000ms, rather than <100ms as other browsers do.

[Alexey Proskuryakov]

There is no test case attached at the moment, please attach it.

[Alan Tam]

Created attachment 86471 [details]
Test case

Really attach the test case.

[Alexey Proskuryakov]

<rdar://problem/9169336>

[Geoffrey Garen]

Initial times are even (between Safari 5.0.3 and TOT), but TOT starts to skyrocket upward from there. Safari 5.0.3 does have one or two very long pauses on the order of TOT, but TOT has very long pauses during each iteration.

[Geoffrey Garen]

Safari 5.0.3 beginning:
[A] Last pass took 43ms
[A] Last pass took 48ms
[A] Last pass took 65ms
[A] Last pass took 30ms
[A] Last pass took 31ms
[A] Last pass took 101ms

TOT beginning:
[A] Last pass took 52ms
[A] Last pass took 58ms
[A] Last pass took 60ms
[A] Last pass took 69ms
[A] Last pass took 84ms
[A] Last pass took 95ms

TOT later:
[A] Last pass took 1119ms
[A] Last pass took 1153ms
[A] Last pass took 1168ms
[A] Last pass took 1184ms
[A] Last pass took 1200ms
[A] Last pass took 1215ms

[Geoffrey Garen]

Created attachment 87197 [details]
Patch

[Geoffrey Garen]

Committed r82162: <http://trac.webkit.org/changeset/82162>

[Geoffrey Garen]

Reopening, since my patch didn't fix the whole regression.

[Geoffrey Garen]

Updating title to reflect the specific constraints of this test: it allocates a 2GB tree!

Most of the run-time is dominated by OS virtual memory allocation, fault, and zero fill calls.

[Geoffrey Garen]

Some regression ranges:

77699 (fast) - 80051 (slow) [actually 78312]
-> The capacity() bug, which was fixed in <http://trac.webkit.org/changeset/82162>.

80051 (fast) - 80052 (slow)
-> Changing the block size to 16KB.

[Geoffrey Garen]

Testing in other browsers:

Firefox aggressively grows the heap to 2GB, and never shrinks it. This is the fastest possible policy for this stress test (~2s total), but a very bad policy for memory footprint!

Chrome is pretty fast (~3.5s total) on its first run, but gets very slow (>30s total or complete hang) on later runs.

[Geoffrey Garen]

> Firefox aggressively grows the heap to 2GB, and never shrinks it.

Correction: It looks like Firefox will eventually shrink from 2GB if you give it enough cajoling.

[Geoffrey Garen]

It looks like the fundamental underlying problem here is that vm_map is O(N^2).

[Geoffrey Garen]

Comment on attachment 87197 [details]
Patch

Clearing review flag to get this out of the list.