search

dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.3k stars 1.59k forks source link

[VM Service Protocol] Support lazily computing bound variables for frames #43827

Open grouma opened 4 years ago

grouma commented 4 years ago

The VM Service protocol requires all bound variables to be computed for a frame. Each bound variable, for web debugging, potentially requires an evaluation in Chrome to compute which introduces latency. However, VS Code supports lazily displaying bound variables when a user selects a given frame in the stack. We should modify the VM Service protocol to support this lazy computation. We can either introduce a new call like boundVariablesFor(Frame) or introduce the concept of a boundVariableRef.

grouma commented 4 years ago

Related to https://github.com/dart-lang/webdev/issues/993 and https://github.com/dart-lang/sdk/issues/43826

bkonyi commented 3 years ago

As proposed by @jacob314 offline:

A simpler way to provide this API could be to provide one version of the getStackTrace API that does not specify any bound variables. The field is already optional in Frame.

devoncarew commented 3 years ago

OK, I see the definition of getStack() here: https://github.com/dart-lang/sdk/blob/master/runtime/vm/service/service.md#getstack. The proposal is to add something like an optional don'tPopulateVariables parameter to the call?

How would users go from an unpopulated Frame (https://github.com/dart-lang/sdk/blob/master/runtime/vm/service/service.md#frame) then to one populated with bound variables? Would the getObject() call return a populated frame? I see that Frame is a Response, and doesn't have an object ID.

cc @jacob314 @bkonyi @grouma

jacob314 commented 3 years ago

The simplest solution is getStack could have a starting frame index as well as an ending frame index which matches what other debugger protocols support. Adding a frameId would also be reasonable and the debugger adapter protocol supports both. Both would be easy enough for dwds to support.