Editorial: Various changes around execution contexts #2962

jmdyck · 2022-11-22T04:48:42Z

This PR follows up on some things that came up in the discussion of PR #2665, and then goes farther.

I've organized it into a bunch of fairly focused commits, in case that helps with review. The commits are divided into 3 groups.

(Commits marked with "(see commit msg)" have some extra discussion in the commit message.)

Transfer control:
- Replace the 6 "Resume the suspended evaluation" steps (next-side).
- Replace the 3 remaining blocking-Resume steps (yield-side).
- Refactor GeneratorStart's sub-algorithm so that it has only one Return step.
- Replace 3 Return steps (yield-side). (see commit msg.)
- Re-word some steps that talk about resuming execution contexts.
- Define "transfer control".
Resume+Suspend:
(I think these resolve Clarify Running Execution context and the impact of push/pop and suspend/resume #2409.)
- Eliminate Resume steps. (see commit msg)
- Eliminate Suspend steps. (see commit msg)
Execution Context section:
- Move a paragraph
- Make the EC Stack subsection (see commit msg)

One of the side-effects is to treat execution contexts more like just data structures. I.e., an EC isn't an active thing, it doesn't execute code, and suspending/resuming it makes no more sense than suspending/resuming a List or Record. If you like that direction, I could do some more cleanup. (I don't think there's much left.)

See also PR #2246 and PR #2681, which are independent of this PR but in the same conceptual neighborhood.

jmdyck · 2022-11-22T22:58:53Z

(force-pushed to fix an 'unused-declaration' error from ecmarkup)

jmdyck · 2023-01-14T01:46:44Z

Force-pushed to resolve merge-conflicts from PR #2681.

Also, I've added a fixup commit that makes 'code evaluation state' a bit more concrete.

michaelficarra · 2023-01-25T17:47:42Z

spec.html

+    </ul>
+    <p>The suspended execution associated with _aContext_ will stay suspended until some step transfers control back to _aContext_, which might never happen.</p>
+    <emu-note>This is analogous to the concept of coroutines in programming languages.</emu-note>
+    <emu-note>In practice, _aContext_ was the running execution context until just before the “transfer control” step, and _bContext_ is the new running execution context. However, the “transfer control” step itself doesn't manipulate the execution context stack.</emu-note>


Why is this note needed? Who does this clarification help, and what does it help them with?

I think it helps the person who reads the definition of "transfer of control" and thinks "But wait, if you transfer control to an execution context, does that make it the running execution context? Does 'transfer control' also manipulate the execution context stack?" (Similar to issue #2409. Not that exact question, but a similar uncertainty about implicit stack manipulation.)

Now, in the absence of that note, I think you could still answer those questions by going to the places where 'transfer of control' occurs, and seeing what happens to the EC stack in neighboring steps. But I think it's useful to have a note to this effect close to the definition of 'transfer of control'.

michaelficarra · 2023-01-25T17:50:53Z

spec.html

+      <h1>Execution Context Stack</h1>
+      <p>An agent's <dfn id="execution-context-stack" variants="execution context stacks">execution context stack</dfn> is used to organize some or all of the agent's execution contexts. The running execution context is always the top element of this stack.</p>
+      <p>Adding and removing always happens at the “top” of the execution context stack. When an execution context is added, it becomes the topmost (i.e., the running execution context), and when it is later removed, the execution context “below” it becomes topmost again.</p>
+      <emu-note>In the absense of generators, every execution context that is pushed onto the stack is new, and when it's removed from the stack it can be discarded. With generators, some execution contexts outlive their time on the stack, exist for a while outside the stack, and then later are pushed onto the stack again.</emu-note>


I love this note.

Though it should be expanded to include async functions.

For symmetry, should I also change "generators" to "generator functions"? E.g. "In the absence of generator functions and async functions, ..."

Eh, I'm fine with the asymmetry (since there actually is a distinction between "generator" vs "generator function", although not one which is relevant here), and I think it reads better without the extra word.

michaelficarra · 2023-01-25T17:55:11Z

spec.html

+        1. Remove _scriptContext_ from the execution context stack and restore the execution context that is at the top of the execution context stack as the running execution context.
        1. Assert: The execution context stack is not empty.


Suggested change

1. Remove _scriptContext_ from the execution context stack and restore the execution context that is at the top of the execution context stack as the running execution context.

1. Assert: The execution context stack is not empty.

1. Remove _scriptContext_ from the execution context stack.

1. Assert: The execution context stack is not empty.

1. NOTE: The execution context that is at the top of the execution context stack is now the running execution context.

We don't make something the running execution context. By the definition of the term, it just is because of its position on the top of the stack.

I think your point is that the wording "and restore ... as the running execution context" misleadingly suggests the need to do something (extra) to make that happen. I basically agree.

However, the "Remove ... and restore ..." wording is well-established in the status quo, in lots of places that this PR doesn't touch, so fixing it should probably be the job of a different PR.

[Later: I made it the first commit of this PR.]

michaelficarra · 2023-01-25T17:57:17Z

Do we need any wording about what it means for "the running execution context" if the execution context stack is somehow empty? Do we need to describe extra invariants about the non-emptiness of the execution context stack?

spec.html

jmdyck · 2023-01-25T22:01:14Z

Hm, maybe the 2 commits for "Execution Context section" should be in a separate PR.

jmdyck · 2023-02-13T16:33:55Z

One of the side-effects is to treat execution contexts more like just data structures. I.e., an EC isn't an active thing, it doesn't execute code, and suspending/resuming it makes no more sense than suspending/resuming a List or Record. If you like that direction, I could do some more cleanup. (I don't think there's much left.)

I've added a commit that eliminates wording that treats execution contexts as 'active' things. Specifically, it eliminates phrasing such as:

an EC tracks the evaluation/execution of code
an EC evaluates/executes code
an EC can wait for an event
code is 'within' an EC
code is evaluated within an EC
control enters an EC

For example, 19 The Global Object says that the global object "is created before control enters any execution context". But the spec doesn't say what it means for control to enter an EC, or when that first happens. (It doesn't use the phrase anywhere else.) And if you (reasonably) guess that it happens when you create an EC and push it onto the stack, that conflicts with InitializeHostDefinedRealm: the global object is created after an EC is pushed onto the stack. So rather than talk about control entering an EC, it seems way more helpful to just say that the global object is created in InitializeHostDefinedRealm.

For another example, 9.9 Forward Progress says that "An agent becomes 'blocked' when its running execution context waits [...] for an external event." But if you look at Atomics.wait and SuspendAgent, there's no mention of anything happening to an execution context, so it seems unnecessary to bring that into the definition of 'blocked'.

jmdyck · 2023-02-13T16:47:45Z

(I didn't eliminate the phrase 'running execution context', despite the fact that it suggests an execution context can 'run'. If we wanted to avoid that, we could call it something like the 'current execution context' or the 'top execution context'. But that would be a lot more disruption for not much benefit, I think.)

jmdyck · 2023-03-01T01:42:53Z

(force-pushed to resolve conflicts from PR #3016)

jmdyck · 2023-03-18T14:39:20Z

(force-pushed to resolve merge conflict)

jmdyck · 2023-03-22T00:46:31Z

(force-pushed to resolve conflict from #3031)

jmdyck · 2023-04-20T22:10:47Z

(force-pushed to resolve merge conflicts)

michaelficarra · 2023-08-30T00:27:37Z

spec.html

        1. Push _scriptContext_ onto the execution context stack; _scriptContext_ is now the running execution context.
        1. Let _script_ be _scriptRecord_.[[ECMAScriptCode]].
        1. Let _result_ be Completion(GlobalDeclarationInstantiation(_script_, _globalEnv_)).
        1. If _result_.[[Type]] is ~normal~, then
          1. Set _result_ to Completion(Evaluation of _script_).
          1. If _result_.[[Type]] is ~normal~ and _result_.[[Value]] is ~empty~, then
            1. Set _result_ to NormalCompletion(*undefined*).
-        1. Suspend _scriptContext_ and remove it from the execution context stack.
+        1. Remove _scriptContext_ from the execution context stack and restore the execution context that is at the top of the execution context stack as the running execution context.


This still sounds like we are requiring some action be taken.

Suggested change

1. Remove _scriptContext_ from the execution context stack and restore the execution context that is at the top of the execution context stack as the running execution context.

1. Remove _scriptContext_ from the execution context stack. The execution context that is now at the top of the execution context stack is the running execution context.

We could also just drop that second sentence.

Okay, I've prepended a commit that eliminates the phrasing "restore [context] as the running execution context".

michaelficarra · 2023-08-30T00:28:54Z

spec.html

+              1. Let _finalCompletion_ be _result_.
+            1. Let _callerContext_ be the running execution context.
+            1. Transfer control from _acGenContext_ to _callerContext_, passing _finalCompletion_.
+            1. NOTE: The above step never completes, because control is never transferred back to _acGenContext_.


Suggested change

1. NOTE: The above step never completes, because control is never transferred back to _acGenContext_.

1. NOTE: This step is never reached because control is never transferred back to _acGenContext_.

I don't want to have to think about what it means for a step to complete.

michaelficarra · 2023-08-30T00:29:46Z

spec.html

-          1. <emu-meta effects="user-code">Resume the suspended evaluation of _genContext_</emu-meta> using NormalCompletion(_value_) as the result of the operation that suspended it. Let _result_ be the value returned by the resumed computation.
-          1. Assert: When we return here, _genContext_ has already been removed from the execution context stack and _methodContext_ is the currently running execution context.
+          1. Transfer control from _methodContext_ to _genContext_, passing NormalCompletion(_value_).
+          1. NOTE: The above step completes only if/when control is transferred back to _methodContext_.


Suggested change

1. NOTE: The above step completes only if/when control is transferred back to _methodContext_.

1. NOTE: This step is reached only if/when control is transferred back to _methodContext_.

jmdyck · 2023-09-22T18:41:29Z

(force-pushed to resolve merge conflicts)

jmdyck · 2024-01-09T19:36:33Z

Force-pushed to rebase to main, and add a fixup commit.

…ext" Specifically, change: > Remove _X_ from the execution context stack and restore the execution context that is at the top of the execution context stack as the running execution context. to just: > Remove _X_ from the execution context stack. and change: > Remove _X_ from the execution context stack and restore _Y_ as the running execution context. to: > Remove _X_ from the execution context stack. > Assert: _Y_ is the running execution context again. The "restore" phrasing suggests that the implementation needs to do something, when in fact the context in question becomes the running execution context automatically, because the running execution context is always the top element of the execution context stack.

…t it has only one Return step.

In GeneratorStart, AsyncGeneratorStart, and AsyncBlockStart, the Abstract Closure ends with a `Return`. This is odd, because where would it return to? Normally, a `Return` would return to the operation that invoked the Abstract Closure, but in this case, the invocation mechanism is unusual, and in general, the operation that caused it is no longer waiting for a result. Instead, the `Return` is presumably supposed to send control back to the latest next-side `Transfer control` step. So make that explicit.

…on contexts

The only remaining `Resume` steps are the 3 non-blocking Resumes in ScriptEvaluation, ExecuteModule, and PerformEval. Since there's no definition for "resuming" an execution context, and since it doesn't come up any other time that an EC is removed from the EC stack, I'm concluding that it has no normative effect. So remove the remaining `Resume` steps.

As with `Resume`, there's no definition for "suspending" an execution context. And if `Resume` has no normative effect, it seems very unlikely that `Suspend` would. So drop mentions of suspending an execution context. ---- The "Execution Contexts" section does have a paragraph that talks about suspending execution contexts, but it doesn't really say what the effect of `Suspend` is, it just implies that it's a prerequisite for making a different EC become the running EC. But that seems like a pointless hoop to jump through. Whatever meaning you might ascribe to suspending an execution context, you could just as easily imagine that it happens automatically whenever the running execution context changes. There's no need for the spec to call it out explicitly. It's just a source of "bugs", where we fail to say it when we "should".

Take a paragraph that talks about LexicalEnvironment and VariableEnvironment, and move it to a better spot.

Collect stuff about the execution context stack, move it to a new subsection, and then rework it. Note that there a couple of problems in the status quo: "A new execution context is created whenever control is transferred from the executable code associated with the currently running execution context to executable code that is not associated with that execution context." That became false when generators were added. "Transition of the running execution context status among execution contexts usually occurs in stack-like last-in/first-out manner. However, some ECMAScript features require non-LIFO transitions of the running execution context." No, it's always stack-like.

Formerly, we would say: Set the code evaluation state of _genContext_ such that the next time there is a transfer of control to that execution context, _closure_ will be called with no arguments. I.e., we don't say what to set it *to*, just what the eventual effect of the setting should be. This isn't how the spec usually talks. Instead, simply set the code evaluation state to _closure_, and define "transfer of control" to handle that appropriately.

Specifically, eliminate wording such as: - an EC tracks the evaluation/execution of code - an EC evaluates/executes code - an EC can wait for an event - code is 'within' an EC - code is evaluated within an EC - control enters an EC

…ached"

jmdyck · 2024-01-11T01:22:37Z

(force-pushed to resolve merge conflicts)

jmdyck added the editorial change label Nov 22, 2022

jmdyck force-pushed the transfer branch from 514b0b4 to 6e98e38 Compare November 22, 2022 22:55

jmdyck force-pushed the transfer branch from 6e98e38 to 94b2244 Compare January 14, 2023 01:46

bakkot added the editor call to be discussed in the next editor call label Jan 18, 2023

michaelficarra reviewed Jan 25, 2023

View reviewed changes

spec.html Outdated Show resolved Hide resolved

jmdyck force-pushed the transfer branch from 94b2244 to 45b4498 Compare February 13, 2023 16:33

jmdyck force-pushed the transfer branch from e0d8e8f to 9967f33 Compare March 1, 2023 01:42

michaelficarra removed the editor call to be discussed in the next editor call label Mar 1, 2023

michaelficarra mentioned this pull request Mar 7, 2023

Editorial: mark a note step as a note #3026

Merged

jmdyck force-pushed the transfer branch from 9967f33 to 3b7e84b Compare March 18, 2023 14:38

jmdyck force-pushed the transfer branch from 3b7e84b to b611e23 Compare March 22, 2023 00:46

jmdyck force-pushed the transfer branch from b611e23 to 0dbc50e Compare April 20, 2023 22:10

jmdyck force-pushed the transfer branch from 0dbc50e to e19db45 Compare August 17, 2023 23:01

michaelficarra reviewed Aug 30, 2023

View reviewed changes

jmdyck force-pushed the transfer branch from e19db45 to 6c504e9 Compare September 3, 2023 01:18

jmdyck force-pushed the transfer branch from 6c504e9 to 6fd20a7 Compare September 22, 2023 18:41

jmdyck force-pushed the transfer branch from 6fd20a7 to 6893234 Compare January 9, 2024 19:35

jmdyck added 15 commits January 10, 2024 17:45

Transfer control: Replace the 6 "Resume the suspended evaluation" steps

2e6ff14

Transfer control: Replace the 3 remaining blocking-Resume steps

761eaba

(Transfer control:) Refactor GeneratorStart's Abstract Closure so tha…

9f2146c

…t it has only one Return step.

Transfer control: Re-word some steps that talk about resuming executi…

7d83fbb

…on contexts

Transfer control: Define "transfer control"

2d3e0a7

Execution Context section: Move a paragraph

0007df7

Take a paragraph that talks about LexicalEnvironment and VariableEnvironment, and move it to a better spot.

Eliminate certain wording around execution contexts

8c1b360

Specifically, eliminate wording such as: - an EC tracks the evaluation/execution of code - an EC evaluates/executes code - an EC can wait for an event - code is 'within' an EC - code is evaluated within an EC - control enters an EC

fixup: Insert "and async functions" into note re execution contexts

85de8ab

fixup: "The above step [never] completes" -> "This step is [never] re…

1f40ed7

…ached"

jmdyck force-pushed the transfer branch from 6893234 to 1f40ed7 Compare January 11, 2024 01:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Editorial: Various changes around execution contexts #2962

Editorial: Various changes around execution contexts #2962

jmdyck commented Nov 22, 2022

jmdyck commented Nov 22, 2022

jmdyck commented Jan 14, 2023

michaelficarra Jan 25, 2023

jmdyck Jan 25, 2023

michaelficarra Jan 25, 2023

bakkot Feb 13, 2023

jmdyck Feb 15, 2023

bakkot Feb 15, 2023

jmdyck Feb 16, 2023

michaelficarra Jan 25, 2023

jmdyck Jan 25, 2023 •

edited

michaelficarra commented Jan 25, 2023

jmdyck commented Jan 25, 2023

jmdyck commented Feb 13, 2023

jmdyck commented Feb 13, 2023

jmdyck commented Mar 1, 2023

jmdyck commented Mar 18, 2023

jmdyck commented Mar 22, 2023

jmdyck commented Apr 20, 2023

michaelficarra Aug 30, 2023

jmdyck Sep 3, 2023

michaelficarra Aug 30, 2023

jmdyck Jan 9, 2024

michaelficarra Aug 30, 2023

jmdyck Jan 9, 2024

jmdyck commented Sep 22, 2023

jmdyck commented Jan 9, 2024

jmdyck commented Jan 11, 2024

		1. Remove _scriptContext_ from the execution context stack and restore the execution context that is at the top of the execution context stack as the running execution context.
		1. Assert: The execution context stack is not empty.

	1. NOTE: The above step never completes, because control is never transferred back to _acGenContext_.
	1. NOTE: This step is never reached because control is never transferred back to _acGenContext_.

	1. NOTE: The above step completes only if/when control is transferred back to _methodContext_.
	1. NOTE: This step is reached only if/when control is transferred back to _methodContext_.

Editorial: Various changes around execution contexts #2962

Are you sure you want to change the base?

Editorial: Various changes around execution contexts #2962

Conversation

jmdyck commented Nov 22, 2022

jmdyck commented Nov 22, 2022

jmdyck commented Jan 14, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmdyck Jan 25, 2023 • edited

Choose a reason for hiding this comment

michaelficarra commented Jan 25, 2023

jmdyck commented Jan 25, 2023

jmdyck commented Feb 13, 2023

jmdyck commented Feb 13, 2023

jmdyck commented Mar 1, 2023

jmdyck commented Mar 18, 2023

jmdyck commented Mar 22, 2023

jmdyck commented Apr 20, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmdyck commented Sep 22, 2023

jmdyck commented Jan 9, 2024

jmdyck commented Jan 11, 2024

jmdyck Jan 25, 2023 •

edited