Yang: any thoughts on if we can have the best of both worlds and do full compilation without using much memory?

If I understood correctly, this is about peak memory use, which can be bad because during eager compilation, we recursively compile inner functions.

I think Ross and Toon have some ideas about scheduling compile tasks. The trick here is to figure out whether it is the full AST that causes the memory to peak.

It used to be that we would compile inner functions while we are still compiling the outer function, hence retaining a lot of memory.

However, since then we have moved on to a compile job based approach, which queues compile jobs, each owning its own Zone. There is still recursion going on [0].

Can we make sure that the outer job is destructed to free up the zone before moving on to inner jobs?

[0] https://cs.chromium.org/chromium/src/v8/src/compiler.cc?q=ExecuteUnoptimizedCompileJobs&sq=package:chromium&g=0&l=466

Seems like it's not that easy. We put all these compilation jobs onto a list in order to finalize them at the end, presumably to be able to offload these jobs onto a background task and only finalize them on the main thread at the end.

In this particular case however we compile everything eagerly on the main thread. Can we finalize each job one by one? I would imagine adding a mode to ExecuteUnoptimizedCompileJobs telling it whether we are running exclusively on the main thread. In that case we would call FinalizeCompilationJob after every job and not add it to the inner_function_jobs list. WDYT?

Let me cook up something here :)

Pending change: https://chromium-review.googlesource.com/c/v8/v8/+/1322949/

For this script:

function f() {
  function g1() {
    function h1() {
      function i1() {}
      function i2() {}
    }
    function h2() {
      function i1() {}
      function i2() {}
    }
  }
  function g2() {
    function h1() {
      function i1() {}
      function i2() {}
    }
    function h2() {
      function i1() {}
      function i2() {}
    }
  }
}


The zone memory tracked by the AccountingAllocator before this CL:

peak memory after init:              8192
peak memory after lazy compile:     41200
peak memory after lazy compile:     41200
peak memory after eager compile:   164256


And after:

peak memory after init:              8192
peak memory after lazy compile:     41200
peak memory after lazy compile:     41200
peak memory after eager compile:    41376

If we don't already, we should probably use a different zone for parse and compile so we can drop the large ast at least?

We already use different zones for parse and compile. The issue here is that if we finalize everything at the end, we keep every zone alive until the end.

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

commit 0a7e08ef26fb6afe473f7a51809207894c588f84
Author: Yang Guo <yangguo@chromium.org>
Date: Thu Nov 08 07:29:15 2018

[compiler] finalize compile jobs asap when compiling on main thread

Previously, we finalize all compile jobs at once. This keeps the zone memory
in every compile job alive until the end. This contributes to a high peak
memory when many functions are compiled eagerly, for example when producing
cache data for the ServiceWorker cache.

Memory tracked by the AccountingAllocator in bytes, prior to this change in
the test case:
peak memory after init:              8192
peak memory after lazy compile:     41200
peak memory after lazy compile:     41200
peak memory after eager compile:   164256

With this change, if we are compiling on the main thread, we finalize every
compile job as soon as it is done and dispose the compile job and its zone
memory.

After this change:
peak memory after init:              8192
peak memory after lazy compile:     41200
peak memory after lazy compile:     41200
peak memory after eager compile:    41376

R=leszeks@chromium.org, rmcilroy@chromium.org

Bug:  chromium:901329 
Change-Id: Iae0c89396c89692c4ecdeec3970d3c62031d2bce
Reviewed-on: https://chromium-review.googlesource.com/c/1322949
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57340}
[modify] https://crrev.com/0a7e08ef26fb6afe473f7a51809207894c588f84/src/compiler.cc
[modify] https://crrev.com/0a7e08ef26fb6afe473f7a51809207894c588f84/test/cctest/test-compiler.cc

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

commit ec55cc0f6fa7d99103d22ddcf06012a7bba58f51
Author: Yang Guo <yangguo@chromium.org>
Date: Thu Nov 08 09:37:13 2018

Fix test expectations for compiler peak memory

TBR=machenbach@chromium.org

Bug:  chromium:901329 
Change-Id: Id9bc01e7e49c90ac3b5bca88abba53a38a1b0d80
Reviewed-on: https://chromium-review.googlesource.com/c/1326021
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57348}
[modify] https://crrev.com/ec55cc0f6fa7d99103d22ddcf06012a7bba58f51/test/cctest/test-compiler.cc