Blazor WASM unmarshalled interop with JSImport

[Hooterr]

Hi all,
I need to use JS interop without JSON overhead (too slow, too much data).
I was following examples in the docs that use IJSUnmarshalledRuntime, but is deprecated now. and the docs say I should use JSImportAttribute. Ok fair enough but I can't find the same example for JSImport as there was for the deprectaed interface. Namely a managed object in .NET (struct) passed to JS via a pointer and then read with Blazor.platform.readStringField using offsets.

Here is what I have

[JSImport("globalThis.test2")]
public static partial void Test2([JSMarshalAs<JSType.Any>] object param);
...
JsUnmarshalled.Test2(new InteropStruct()
{
    Name = "Brigadier Alistair Gordon Lethbridge-Stewart",
    Year = 1968,
});

JS

function test2(flights){
    console.log(flights);
    const name = Blazor.platform.readStringField(flights, 0);
    const year = Blazor.platform.readInt32Field(flights, 8);
    console.log(`${name} (${year})`)
}

But I'm getting null when reading name value. Looks like readStringField expects a pointer as a number but instead generated interop code passes ManagedObject Symbol(wasm js_owned_gc_handle): 118 into test2 function.
Not sure how to get an actual heap pointer from that in JS.

I tried another way

[JSImport("globalThis.test2")]
public static partial void Test([JSMarshalAs<JSType.Number>] int param);

and call it like this:

var a = new InteropStruct()
{
    Name = "Brigadier Alistair Gordon Lethbridge-Stewart",
    Year = 1968,
};
IntPtr tr = (int)&a;

JsUnmarshalled.Test(tr.ToInt32());

That worked. But I'm pretty sure that's not how it's supposed to be used. On the other hand the function I wan to call is supposed to decode fields from my managed .net object, copy then, and create JS objects to be used in JS. The function would be synchronous. If I'm not mistaken I don't really need to worry about GC moving my object somewhere else since GC can only do that after my JS function completes.

I know that's a niche usecase but maybe someone has some ideas on how to do this correctly?

The struct for completness

[StructLayout(LayoutKind.Explicit)]
public struct InteropStruct
{
    [FieldOffset(0)]
    public string Name;

    [FieldOffset(8)]
    public int Year;
}

[maraf]

cc @pavelsavara

[pavelsavara]

At the moment we don't support marshaling structures with [JSImport].

The [JSMarshalAs<JSType.Any>] will marshal it as a proxy JS objects, just a wrapper around GCHandle.
That's why Blazor's deprecated unsafe pointer based platform.readStringField would not work on it.
We deprecated this because it was really unsafe, because GC could move the managed objects in memory.

You said that you have lot of data.
Possible solutions how you can transfer it:

1. marshal each member of the structure as different parameter of JSImport method. Like void Method(string name, int year)
2. if you have array of InteropStruct[] you can transform it into multiple arrays of simple types. And then marshal it as void Method(string[] names, int[] years). This is what we do in the HTTP client implementation, when we pass HTTP headers to JS.
3. you can use JSON serializer yourself and marshal string. This could be slower. This is what Blazor does.
4. convert it to byte[] and pass that. In your case, the field Name makes it difficult because of the dynamic size.
5. pin it in memory and pass IntPtr. This is tricky, because you will need to pin the string too and deal with the details.

Hope this helps.

[Hooterr]

It's a geojson with a lot of data mostly strings and numbers. Serializing it to either JSON or binary is too slow anyway.

I went with option 1&2. It's still miles faster than normal interop which is great.

Thanks for the response!

[gismofx]

At the moment we don't support marshaling structures with [JSImport].

The [JSMarshalAs<JSType.Any>] will marshal it as a proxy JS objects, just a wrapper around GCHandle. That's why Blazor's deprecated unsafe pointer based platform.readStringField would not work on it. We deprecated this because it was really unsafe, because GC could move the managed objects in memory.

You said that you have lot of data. Possible solutions how you can transfer it:

1. marshal each member of the structure as different parameter of JSImport method. Like void Method(string name, int year)
2. if you have array of InteropStruct[] you can transform it into multiple arrays of simple types. And then marshal it as void Method(string[] names, int[] years). This is what we do in the HTTP client implementation, when we pass HTTP headers to JS.
3. you can use JSON serializer yourself and marshal string. This could be slower. This is what Blazor does.
4. convert it to byte[] and pass that. In your case, the field Name makes it difficult because of the dynamic size.
5. pin it in memory and pass IntPtr. This is tricky, because you will need to pin the string too and deal with the details.

Hope this helps.

Is there any sample code or examples on how to accomplish this? In my case my js function take a few parameters, two strings, two json objects.

[legistek]

We deprecated this because it was really unsafe,

Except this unsafe interop is exactly what you use for RenderTreeFrame's is it not? Y'all aren't the only ones who know how to pointer arithmetic. ;)

I was extensively using the low level interop - in both directions - in order to achieve performance that was not possible with normal Blazor. I understood these were "internal" APIs, but I expected they might change - not be eliminated. Despite the Mono WASM SDK ostensibly still supporting this, as far as I can tell you obfuscated away any ability for us to use these. For example BINDING and MONO appear to be totally inaccessible now. Is there in fact no way to still use the legacy APIs and if so why did you make the decision to nerf such powerful functionality that was frankly necessary to overcome severe performance limitations in the out-of-the-box framework? You kept the stuff Blazor needed but appear to have nuked the rest. If there is any possibility of bringing this back for final release I beg you to do so, otherwise I will likely be stuck on .NET8 indefinitely.

[maraf]

JSImport/Export doesn't support marshalling as JSON (JSMarshalerType.cs), marshalling as JSON is implemented wrapper layer in Blazor. What I was curious about is if using the same APIs that the generated code for JSImport/Export is using would solve supply the ask for custom marshalling method? (Maybe it's not the right idea..)

[legistek]

Ah, right. Well same difference - JSON is what I want to avoid anyway.

The APIs I'd be interested in using are likely the same as what the current marshalling system is using; I'd just then have control over how (or whether) each member of the struct was marshalled.

Wondering if I'd just be better off using Marshal.AllocHGlobal and StructureToPtr or PtrToStructure and then keep reading/writing heap JS side. At least then there's no risk of GC, nor future implementation changes. I had hoped to avoid making an extra copy but it might not make a noticeable difference.

[maraf]

The APIs I'd be interested in using are likely the same as what the current marshalling system is using; I'd just then have control over how (or whether) each member of the struct was marshalled.

Have you looked at the generated code for JSImport/Export? On C# side, you will be able to those APIs directly, but I'm not sure if you would be able to supply the (un)marshalling on JS side. I'm thinking if that's a way to go for advanced scenarios..

[pavelsavara]

The generated code is not doing any magic. It's serializing the arguments into "stack frame like" buffer. StructureToPtr is probably better than meddling with the JSImport generators or its infrastructure. On JS side we expose APIs for working with the heap.

https://github.com/dotnet/runtime/blob/91939711895b6141e1be509ee743a8afb7a64ee7/src/mono/browser/runtime/dotnet.d.ts#L497-L636

There is also Module._malloc and Module._free

[pavelsavara]

In the initial design of JSImport I drafted ability to use [MarshalAs(UnmanagedType.Struct)] but I cut it out of scope.
Mostly because I was not clear who would own the de-allocations.
At the time of Net7 this was not supported by LibraryImport generated style, if I remember correctly.
I would be willing to explore that again, especially if somebody is willing to contribute the implementation end to end.

In the initial design of JSImport I also drafted custom callbacks to be able to de/serialize simple flat structures as JS Object. It added too much complexity and not much benefit. All of this could be done by community in user code.

[gmurray81]

This is really burning us also. We rely on the unmarshalled APIs for marshaling large data across the WASM divide. We were really hoping that this API would never actually be removed. I'm about to do a lot of work to see if I can cram the same stuff across using this JSImport stuff, but my reward at the end it likely that it won't perform as well as the unmarshalled option. When I pinged you guys a while back it didn't sound like this API was actually going to be removed. Pretty miffed that it has been.

[gmurray81]

Cheers :)
yeah, we already have all the JS side heap access, although I know some of it is using APIs that have been yanked. Although if I can remap most of it to Blazor.runtime.* then it should be ok.

This seems much preferable to trying to re-engineer to pass everything as primitives... so I'll give that a go. Good call on the requirement that it not be a local or parameter. That probably would have burned me, lol.

[gmurray81]

Man, I'm salty about all this. MS directed us at the unmarshalled apis in the first place since it was the only way to make our performance goals for transmitting live data in and out of WASM in realtime with any kind of volume, and then when I pinged them after they tagged it with obsolete, I was told that the API would probably just hang around so not to worry about it much. But now I discover it's been unceremoniously yanked hours before I'm taking some time off.

Always knew it might come to this, but hoped it wouldn't... And certainly could have had better timing....

[legistek]

Yeah it can't be local but a parameter is actually ok. No idea why. Method parameter or class field member work. If you take the address of a local variable you still get a value but I was never able to divine how to derive the instance's actual field data from that despite lots of trial and error.

[gmurray81]

Hmm... a bit stumped with arrays... They dropped the utility methods, and I'm not positive the in memory rep is the same....

[gmurray81]

nevermind, brain just wasn't working, think I'm good.

[legistek]

Man, I'm salty about all this.

I'm just as frustrated, but I think the explanation (if not an excuse) is that they want to try to move .NET WASM to multi-threaded and what we're doing is anathema to that. The upside is that because of how Blazor is architected it will always need a hyper-efficient means of sending C# data structures to JS and because Blazor's performance is already borderline they're not going to do anything to make that worse. So as long as Blazor is supported there will always be a way to efficiently send structured data to JS even if we have to pull our hair out with every new .NET version.

And of course worst case scenario there's always the Marshal.AllocHGlobal and StructureToPtr or PtrToStructure route.