Support flat closure contexts in the vm-service protocol

[alexmarkov]

While moving computation of closure contexts into the front-end (#61572), we're making closure contexts more flexible. In future, this would allow us to use different strategies for computation of contexts, such as safe-for-space contexts.

This affects runtime representation of closures in the VM. In particular, the following is changing:

• Closures can capture multiple contexts.
• Contexts can be independent from one another, not linked via parent pointer.

This change should be reflected in the vm-service protocol and its users (DevTools, IDEs etc) should be updated accordingly.

Affected API:

  // The context associated with a Closure instance.
  //
  // Provided for instance kinds:
  //   Closure
  @Context closureContext [optional];

Context.parent is already optional in the vm-service protocol, so it would be non-breaking to eventually omit it.

[bkonyi]

Just to make sure I understand correctly, would a flat closure context effectively be a merged representation of the current way we compute contexts? Or would we be reporting multiple contexts per closure?

If we have a design doc or specification, that would be really helpful to understand if there's anything else other than Context.parent that needs to be changed.

[alexmarkov]

We would be reporting multiple contexts per closure.

Current/old representation: 1 context per closure, hierarchical:

Closure1 --closureContext--> Context1a --parent--> Context2
Closure2 --closureContext--> Context1b --parent--> Context2

New representation: multiple contexts per closure, no hierarchy:

Closure1 --closureContexts--> Context1a, Context2
Closure2 --closureContexts--> Context1b, Context2

So the main difference is that there are now multiple potentially independent contexts per closure.

We should keep supporting optional Context.parent for now to accommodate for the current representation, but eventually after fully switching to the new representation we may also deprecate and drop parent pointer between contexts.

[bkonyi]

Great, thanks for the explanation! So it looks like we'll eventually need to deprecate @Context closureContext and Context.parent, and add @Context closureContexts[]. Will there be a period where we'll have a mix of representations?

[alexmarkov]

It's likely there will be a period where we would have a mix of representations. So ideally we should have an API which would work for both representations. For example, we can add @Context closureContexts[] now and implement it to return either [closureContext] or [for (context = closureContext; context != null; context = context.parent) context] and then transition to the new API.

Alternatively, we can consider contexts to be an implementation detail and avoid exposing them at all. Maybe it would be sufficient to add @Instance capturedValues[] to closure instances to expose the full list of captured values but not their distribution among contexts. WDYT?