Also change the format M{Load,Store}DynamicSlot to append the slot information
at the end, because it was confusing to see a bare number in the middle of the
output for MStoreDynamicSlot. And change MStoreDynamicSlot to print the type
information of its operands.

Later patches will use the scope to retrieve the environment shape. Also assert
in the interpreter that the scope matches the current scope.

Depends on D156777

Add LexicalScope as a GC pointer type and then generate the code
for MNewLexicalEnvironmentObject.

Depends on D156778

Add Warp snapshots which store the template object information for the
environment objects.

Depends on D156779

Use the Warp snapshots to retrieve the environment scopes.

Depends on D156780

Store the template object in the environment instruction and later retrieve
the scope from the template object.

Depends on D156781

This matches MNewCallObject and should help if we ever support scalar
replacement of lexical environment objects.

Depends on D156782

Everything is now in place to allow inline allocation of environment objects.

Depends on D156783

Inline the method in preparation for the next two parts.

Depends on D156784

Use MNewLexicalEnvironmentObject to inline the allocation.

Depends on D156785

Use MNewLexicalEnvironmentObject to inline the allocation and then copy all
slots manually.

Depends on D156786

No longer needed after the last two parts.

Depends on D156787

Add a debug-only check that it's okay to elide the post write barriers.

Depends on D156788

The template object is always present, so a comment mentioning it's only
conditionally present is a bit misleading.

Depends on D156789

• Use createTemplateObject iff creating a template object. This implies the
  object is tenured, so always pass gc::TenuredHeap.
• Add createWithoutEnclosing for Warp to create an environment object without
  an environment oject. The object is never pre-tenured, so always use
  gc::DefaultHeap.
• No public method now accepts a gc::InitialHeap parameter.

Depends on D156801

https://hg.mozilla.org/mozilla-central/rev/f78fd4a216da
https://hg.mozilla.org/mozilla-central/rev/599ac6a9d028
https://hg.mozilla.org/mozilla-central/rev/35754caa8eec
https://hg.mozilla.org/mozilla-central/rev/9cf7225b2029
https://hg.mozilla.org/mozilla-central/rev/2936cd579655
https://hg.mozilla.org/mozilla-central/rev/6e471b207c2f
https://hg.mozilla.org/mozilla-central/rev/96e9152c2cfe
https://hg.mozilla.org/mozilla-central/rev/90917af9e65e
https://hg.mozilla.org/mozilla-central/rev/77b20f516feb
https://hg.mozilla.org/mozilla-central/rev/8afd8f0c47d9
https://hg.mozilla.org/mozilla-central/rev/51c8183e8ac2
https://hg.mozilla.org/mozilla-central/rev/e7f4d971689d
https://hg.mozilla.org/mozilla-central/rev/d385628a29e6
https://hg.mozilla.org/mozilla-central/rev/81dbd17dab44
https://hg.mozilla.org/mozilla-central/rev/48520b1aa12d
https://hg.mozilla.org/mozilla-central/rev/5da07fdf2c5e

(In reply to Nicolas B. Pierron [:nbp] from comment #1)

We should also consider adding it to the escape analysis and recover
instructions, such that we can avoid any allocation if none of their uses
are escaped.

This is tracked in bug 1700382.

Note, adding it as part of the recover instruction would imply splitting the
instruction in 2, such that one can hold the GC pointers in the snapshot,
while the other does the create operation, as is done for NewObject and the
templateObject already.

The patch series for this bug already split the instruction in preparation for possible scalar replacement. The biggest obstacle right now is to somehow recover the scope chain on bailout. We need something like jit::EnsureHasEnvironmentObjects, but instead of only recovering the CallObject, we need to recover the whole scope chain.

(In reply to André Bargull [:anba] from comment #23)

The patch series for this bug already split the instruction in preparation for possible scalar replacement. The biggest obstacle right now is to somehow recover the scope chain on bailout.

Everything should already in place for doing it, as we already support recovering function environment.

Function environment were a bit more tricky due to observable flags from arguments.caller, which causes eager bailout when a value is queried but was never materialized by Ion.

In a case like this (Surrounding caller code omitted):

function f() {
  {
    let x = 0;
    return () => x;
  }
}

JSScript::needsBodyEnvironment() returns true, which leads to returning ObservableNotRecoverable in CompileInfo::getSlotObservableKind(). IsObjectEscaped rejects scalar replacement in this case. (See also bug 1342483.)

I assume changing EnsureHasEnvironmentObjects to recover the whole scope chain could help here.

(Comment update fail.)

(In reply to André Bargull [:anba] from comment #25)

function f() {
  {
    let x = 0;
    return () => x;
  }
}

Well in this case x is escaped via the arrow function which captures it. Scalar Replacement should only be capable of removing it if f is inline, as well as the caller of the result of f.

Yes, I've omitted the surrounding caller code which calls f and the arrow function in the example.

(In reply to André Bargull [:anba] from comment #20)

Created attachment 9293662 [details]
Bug 1341937 - Part 16: Remove extra barrier in CallObject::create ool-path. r=jandem!
Is there some justification for why this barrier is not needed? In general the GC can allocate objects in the tenured heap sometimes even when nursery allocation is requested.

Part 16 was added based on the review comments from part 7: Before this patch stack, CallObject was the only environment object which performed an explicit barrier in the OOL path. Part 16 aligned it with other environment objects, like for example NamedLambdaObject, which don't perform an extra barrier.

In Part 13, I've also added extra assertions to check it's okay to elide these barriers. And there's bug 1622192, created in response to this review, to further clean-up these implicit allocation invariants.