eval: when possible avoid loading chrome scope data

[sigmundch]

(@annagrin - this tracks details of our discussion yesterday.)

When a user requests an evaluation in frame, today we take a few steps:

1. dwds requests frame data from chrome first (like value of locals at that frame scope and parent scopes)
2. it then sends a request to the expression evaluation worker to generate javascript for the evaluated expression, including some scope values
3. the worker wraps the result in a JS function that provides values for all the variables in scope that may be used in the body of the function
4. dwds sends the JavaScript back via the evaluateInFrame API to get a value
5. and so on ...

This bug is to track whether in the future we can conditionally skip the extra round trip to request the frame data (step 1).

Step 1 is currently necessary for two reasons:

• We are missing mappings of variables generated by DDC, without it, we can't ensure the expression compiler generates the same names. Using the scope data reduces the impact of this bug and makes the feature usable.
• The v8 engine may optimize away variables that were not captured by a closure. So if evaluated expressions refer to those variables, they are not available when invoking evaluateInFrame.

We already have plans to solve the symbol mapping (see #40273) to make expression evaluation more robust. After that, it would be nice to avoid the extra round trip when we can.

We believe we may be able to robustly determine when scope information will be needed. If so, we should be able to change the order of steps (1) and (2), so we only incur the extra round trip when it is necessary.

For example, we think will not need the scope data when:

• evaluation is in a frame that corresponds directly to a regular Dart method (so no closures are involved)
• evaluation is in a closure frame, but the evaluated expression only contains variables that are already captured by the closure

@annagrin @grouma - should we track this here or in webdev?

[sigmundch]

For context - recently @Markzipan was looking at whether we could use d8's inspector API to test eval, but this extra round trip prevented us from going down that route. In the future if we address this, it could enable us to use d8's inspector API to also write performance benchmarks.

[annagrin]

I would wait with this until we have supporting performance data - right now I am expecting bigger savings in other parts of the expression evaluation workflow.

We will need to adjust dwds if we have a solution but the current dwds code will still work, so it is fine to create a dwds issue to cleanup when this is solved.

Some corrections: in order to not need to access chrome scope we will need to

• Make a design decision to not support evaluation of non-captured values inside closures
  • currently works for primitive values only
• Know which of the dart symbols do not have counterparts available in JS scope
  • not sure how to get this information without talking to chrome
• Dart <-> js symbol mapping available to the expression compiler (ie in DDC's memory is OK)

Example

Dart code

void foo() {
  int y = 0;
  void inner() {
    int x = 1;
    // breakpoint 1
  }
}

Original JavaScript, loaded to chrome

foo() {
  var js_y = 0
  var inner = function() {
    var js_x = 1;
    //  JS breakpoint 1
  }
}

Synthetic dart function for evaluating x on breakpoint 1

Dart scope: {x, y}
JavaScript scope: {js_x}
Dart to JS scope map: { x: js_x } // Note: we don't have this information available currently.

// Formal parameters: create formals for all dart scope variables that have matching JS variables

void eval$(int x2) { 
   return x2;
}

Synthetic function for evaluating x, compiled to JavaScript

function(js_x2) {
  return js_x2;
}

Expression sent to chrome for evaluation

JavaScript scope: {js_x}
Dart to JS scope map: { x2: js_x2 } // Note: we don't have this information available currently.

// Pass original JS variable (js_x) matching dart variables for 
// dart formals (x) that correspond to JS formal (js_x2)

(function(js_x2) {
  return js_x2;
}) (js_x)