[dart2wasm] High overhead getting JS wrapper for WasmGC objects in new interop API

[mkustermann]

The current way to pass Dart objects to JavaScript with the new interop API is this via Object.toJSBox:

@patch
extension ObjectToJSBoxedDartObject on Object {
  @patch
  JSBoxedDartObject get toJSBox {
    if (this is JSValue) {
      throw 'Attempting to box non-Dart object.';
    }
    final box = JSObject();
    js_helper.JS<WasmExternRef?>('(o,s,v) => o[s] = v', box.toExternRef,
        _jsBoxedDartObjectProperty.toExternRef, jsObjectFromDartObject(this));
    return box as JSBoxedDartObject;
  }
}

The reasoning behind it seems to be safety when mixing dart objects from different dart applications running in the same browser context:

/// Embedded global property for wrapped Dart objects passed via JS interop.
///
/// This is a Symbol so that different Dart applications don't share Dart
/// objects from different Dart runtimes. We expect all [JSBoxedDartObject]s to
/// have this Symbol.

=> Our main user of Dart2Wasm is Flutter4Web where almost certainly only one Dart app runs
=> This makes us pay a high price for something that's very uncommon.

We need to change this. Either

• ignore that (multi-dart-app) aspect entirely (and leave it up to app developers to not mix objects across apps)
• we make it some sort of opt-in (e.g. compiler flag)
• provide public APIs users can use that are faster and don't have this overhead (if a user knows they aren't going to mix objects from different Dart apps)

Interestingly enough js_util.jsify() is high overhead due to many type tests and recursive behavior, but it does not perform the complex mechanism of obtaining JS wrappers. Instead it makes the simple & fast way to get JS wrapper, namely WasmAnyRef.fromObject(object).externalize().toJS.

/cc @srujzs

[srujzs]

Our plan is to do the third option: #55187. We've had some internal discussion a while back and agreed to add this, but we haven't had any external need for this until recently, so this should be a higher priority.

[mkustermann]

Our plan is to do the third option: #55187. We've had some internal discussion a while back and agreed to add this, but we haven't had any external need for this until recently, so this should be a higher priority.

As mentioned on the other issue, passing objects to JS and back again should use the fast mechanism by-default, we shouldn't encourage users to use a slow mechanism and hide the fast one dart:js_interop_unsafe - when in reality there's no safety concerns for them at all.

/cc @sigmundch

[mkustermann]

We now have Object.toExternalReference and ExternalDartReference.toDartObject extension methods, so I'm going to close this issue.

Thanks @srujzs for adding those!

[mkustermann]

Interestingly enough js_util.jsify() is high overhead due to many type tests and recursive behavior, but it does not perform the complex mechanism of obtaining JS wrappers. Instead it makes the simple & fast way to get JS wrapper, namely WasmAnyRef.fromObject(object).externalize().toJS.

@srujzs This seems to be still the case. It may be a discrepancy between dart2js/ddc and dart2wasm. Should this get aligned?

[srujzs]

I believe it's aligned as it is:

sdk/sdk/lib/_internal/js_shared/lib/js_util_patch.dart

Line 62 in 061004f

return o;

. All three compilers return an ExternalDartReference when given an unrelated Dart object. In DDC and dart2js, both this operation and toExternalReference are a no-op. In dart2wasm, they both externalize the Dart object.

There's still the intention of disallowing unrelated Dart objects from being passed to jsify that we discussed here: #55222.

[mkustermann]

All three compilers return an ExternalDartReference when given an unrelated Dart object. In DDC and dart2js, both this operation and toExternalReference are a no-op. In dart2wasm, they both externalize the Dart object.

If we disallow sending unrelated dart objects, then that's fine