1911071 - Initial tunables and heuristics for wasm lazy tiering and speculative inlining

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, enhancement, P3)

Description

[Julian Seward [:jseward]]

When LT+SI is enabled, we'll need some knobs to tune performance. I'm
contemplating the following scheme (as preferences exposed in about:config):

• wasm.lazy_tiering.level: 0 through 9 (default 5)

  • 0 means "infinite threshold" (2^31-1); everything compiled in but will
    "never" tier up

  • 9 means "maximally aggressive" (threshold=0); maximum tiering up

  • 5 is gives a default threshold of our choosing.

  • below 5 gives increasingly higher thresholds (== decreasing aggressiveness)

  • above 5 gives increasingly lower thresholds (== increasing aggressiveness)

  With this, we can get get settings useful for development (default tiering,
  always tier up, never tier up) without users having to make decisions on
  actual threshold numbers, which to them are opaque/meaningless.

• wasm.inlining.level: 0 through 9 (default 5)

  • similar deal to the above

  • 0 means "never inline"

  • 9 means "inline very aggressively"

  • 5 is a "sensible" default

  This might need to get split into direct- and indirect- inlining variants,
  but this seems to be the minimal thing with which we can reasonably get
  started.

The numeric-value-to-signify-some-preset-bundle-of-params thing is inspired by
"-1 .. -9" for (eg) gzip -- see gzip --help.

Comment 1

[Julian Seward [:jseward]]

Attachment: Bug 1911071 - part 1: reorganize lazy-tiering and inlining heuristics. r=yury.

This patch changes the lazy-tiering and inlining heuristics to be more suitable
for production use, and moves them into their own file, WasmHeuristics.h.

• StaticPrefList.yaml

  • remove prefs
    javascript.options.wasm_experimental_inline_depth_limit,
    javascript.options.wasm_experimental_inline_size_limit

  • add more abstract prefs
    javascript.options.wasm_experimental_tiering_level,
    javascript.options.wasm_experimental_inlining_level,
    javascript.options.wasm_experimental_direct_inlining,
    javascript.options.wasm_experimental_callRef_inlining.

• new file WasmHeuristics.h

• new class LazyTieringHeuristics. This reads
  JS::Prefs::wasm_experimental_tiering_level when created and uses that
  information in ::estimateIonCompilationCost to provide some estimate of the
  Ion compilation cost for a function, which is used as the initial hotness
  counter. The basic logic is unchanged from before.

• new class InliningHeuristics. This reads
  JS::Prefs::wasm_experimental_inlining_level and two others at startup. These
  are then used by ::isSmallEnoughToInline to answer inline/no-inline
  questions. The logic is new -- it allows only smaller and smaller functions
  to be inlined as the inlining depth insreases.

• Instance::computeInitialHotnessCounter: use
  LazyTieringHeuristics::estimateIonCompilationCost.

• WasmIonCompile.cpp: shouldInlineCallDirect: rename to shouldInlineCall, and
  use InliningHeuristics::isSmallEnoughToInline to make inlining decisions.

Comment 2

[Julian Seward [:jseward]]

Attachment: Bug 1911071 - part 2: collect and print statistics on lazy-tiering and inlining. r=yury.

This patch adds machinery for collecting statistics on lazy tiering and
inlining. These are stored in the CodeMeta for a module and are printed, using
the MOZ_LOG facility, when the CodeMeta is destructed (at the end of the
module's lifetime). The collected data is minimal but is important for tuning
the LT and inlining heuristics.

• WasmMetadata.{h,cpp}, class CodeMetadata

  • new struct ProtectedStats and lock-protected field stats
  • new method CodeMetadata::dumpStats

• vm/Logging.h: new logging tag 'wasmCodeMetaStats'

• vm/MutexIDs.h: new mutex 'WasmCodeMetaStats' for serializing access to the
  stats

• WasmCode.cpp: copy code-allocation info into CodeMeta::stats

• WasmGenerator.cpp, ModuleGenerator::finishModule: copy complete-tier info
  into CodeMeta::stats

• WasmIonCompile.cpp, class FunctionCompiler:

  • add comment explaining how the FunctionCompiler stack is organized
  • new field toplevelCompiler_, to access the stack base quickly
  • new fields stats_*, temporarily holding stats during compilation of one
    function
  • FunctionCompiler::~FunctionCompiler: copy stats into CodeMeta::stats

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4766ff891576
part 1: reorganize lazy-tiering and inlining heuristics.  r=yury.
https://hg.mozilla.org/integration/autoland/rev/5b7ee12ee96d
part 2: collect and print statistics on lazy-tiering and inlining.  r=yury.

Comment 4

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/4766ff891576
https://hg.mozilla.org/mozilla-central/rev/5b7ee12ee96d

Comment 5

[Mayank Bansal]

29.1% improvement on Jetstream2-HashSet-wasm-Runtime