• Benedikt Meurer's avatar
    [inspector] Implement Debug Proxy API via Interceptors. · c27c167c
    Benedikt Meurer authored
    Previously the Debug Proxy API that's exposed on Wasm frames by
    Runtime.evaluateOnCallFrame() was implemented via actual JSProxy
    instances. That means that all entities such as "memories", "tables",
    "stack", "globals", etc. were JSProxy instances with "get" and "has"
    traps. But that has a couple of down-sides:
    
    1. In DevTools front-end, the proxies are shown as JSProxy, which is not
       very useful to developers, since they cannot interact with them nor
       can they inspect their contents. And the object preview also only
       shows "Proxy {}" for them.
    2. The performance doesn't scale well, which becomes a painful
       bottleneck with larger Wasm modules that contain hundreds of
       thousands of functions or globals.
    3. We cannot use the JSProxy instances in the Scope view (for the
       reasons outlined in 1.) and hence we have different logic to provide
       Scope values than values in the rest of DevTools, which led to subtle
       but annoying bugs and inconsistencies.
    
    This also changes the "locals" implementation by querying the values
    ahead of time, similar to the object exposed to the Scope view, instead
    of on-demand, since the "locals" object might survive the current
    debugger pause and peeking into the stack afterwards would read invalid
    memory (and might even be a security issue). For being able to change
    locals we need to look into a similar solution as what we have for
    JavaScript locals already. The expression stack already works this way.
    
    For performance reasons (especially scaling to huge, realistic Wasm
    modules), we cache the per-instance proxies ("functions", "memories",
    "tables" and "globals") on the WasmInstanceObject and reuse them (which
    is safe since they have a `null` prototype and are non-extensible), and
    we also cache the proxy maps (with the interceptors) on the
    JSGlobalObject per native context.
    
    Doc: http://bit.ly/devtools-wasm-entities
    Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241
    Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058
    Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
    Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
    Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#71981}
    c27c167c
wasm-debug.cc 72.9 KB