1259796 - Update stack frame measurements

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Emanuel Hoogeveen [:ehoogeveen]]

There's a great comment in XPCJSRuntime.cpp [1] about how the various JS stack limits were decided. However, the actual constants have been adjusted several times and unfortunately the comment has not always been updated to match. Now is a good time to remeasure since we just switched to compiling with Visual Studio 2015 on Windows.

In bug 1010556, nbp added a little shell testcase [2] and testing function to make these measurements easier. I've adapted this into a browser chrome mochitest locally, to catch any effects PGO might have.

One thing to note about this testcase, and the original added by bholley [3], is that they both assume that |with| is not compiled. However, |with| actually *does* get baseline compiled these days. In practice, however, baseline frames are actually *larger* than interpreter frames, so these testcases still measure the correct thing (I confirmed this by passing --setpref javascript.options.baselinejit=false to the test harness).

Initial non-PGO results give a stack frame size of 9475 bytes with the baseline JIT enabled, and 6740 bytes with it disabled. Since IIUC baseline should kick in after 10 iterations, the actual baseline stack frame size may be something more like 9600 bytes. The PGO numbers are what really matters, though, so I'll get those next.

[1] https://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#3435
[2] https://dxr.mozilla.org/mozilla-central/source/js/xpconnect/tests/chrome/test_bug732665_meta.js
[3] https://dxr.mozilla.org/mozilla-central/source/js/xpconnect/tests/chrome/test_bug732665.xul

Comment 1

[Emanuel Hoogeveen [:ehoogeveen]]

I should specify: those initial measurements were done on a local 64-bit opt build.

Comment 2

[Jan de Mooij [:jandem]]

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #0)
> In practice, however,
> baseline frames are actually *larger* than interpreter frames, so these
> testcases still measure the correct thing (I confirmed this by passing
> --setpref javascript.options.baselinejit=false to the test harness).

In case anyone wonders, that's likely because the test keeps calling out into the VM and then back into JIT code, that consumes a fair amount of stack space (I've been meaning to improve this but it's complicated).

Comment 3

[Emanuel Hoogeveen [:ehoogeveen]]

These are the local numbers I've gathered (had to wait for some calculations to finish before I could do the PGO runs):

win32 Opt:
  Baseline JIT: 4506 bytes per frame
  Interpreter:  3598 bytes per frame

win32 Opt PGO:
  Baseline JIT: 5135 bytes per frame
  Interpreter:  4126 bytes per frame

win32 Opt Debug:
  Baseline JIT: 4234 bytes per frame
  Interpreter:  3010 bytes per frame

win64 Opt:
  Baseline JIT: 9475 bytes per frame
  Interpreter:  6740 bytes per frame

win64 Opt PGO:
  Baseline JIT: 9242 bytes per frame
  Interpreter:  7400 bytes per frame

win64 Opt Debug:
  Baseline JIT: 9362 bytes per frame
  Interpreter:  6880 bytes per frame

So win64 frames are a bit over twice as big as win32 frames, but the numbers are pretty consistent and PGO doesn't produce especially huge frames. I don't know if that's due to the switch to MSVC 2015, due to PogoSafeMode (bug 1249923) or both, but we should be able to lower the current numbers by a fair bit. Probably worth a couple of try runs to see if things look the same in automation.

Comment 4

[Emanuel Hoogeveen [:ehoogeveen]]

Here are numbers from try:

Linux   32-bit opt:    2983 bytes
Linux   32-bit debug:  3579 bytes
Linux   64-bit opt:    6446 bytes
Linux   64-bit asan:  18327 bytes
Linux   64-bit debug:  6531 bytes
OSX            opt:    4931 bytes
OSX            debug:  5862 bytes
Windows 32-bit opt:    4511 bytes
Windows 32-bit debug:  4234 bytes
Windows 64-bit opt:    9488 bytes
Windows 64-bit debug:  9367 bytes

Linux   32-bit PGO:    3039 bytes
Linux   64-bit PGO:    5934 bytes
Windows 32-bit PGO:    5146 bytes
Windows 64-bit PGO:    9613 bytes

The OSX PGO build failed for some reason; maybe it's triggered in a different way in production. This also nicely confirms that ASAN makes stack frames ~3x as big.

Jan is still in the middle of landing his stack-related changes; I'll hold off producing a patch here until that's done. He also mentioned on IRC that these numbers tend to spike occasionally, so we should probably use fairly conservative estimates. I think it's worth getting these up-to-date, though.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

We don't ship OSX PGO builds.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.