[wasm][nodejs] implement synchronous DLL loading

[pavelsavara]

• on nodeJS and v8 we could load DLLs synchronously on-demand
• without need to pre-load them via mono-config.json
• we should respect PATH same way as normal desktop dotnet

cc @maraf @lewing

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• on nodeJS and v8 we could load DLLs synchronously on-demand
• without need to pre-load them via mono-config.json
• we should respect PATH same way as normal desktop dotnet

cc @maraf @lewing

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript
Milestone:	8.0.0

[maraf]

@lambdageek has an idea of creating an abstraction in the runtime that will allow to us to load only parts of the managed assemblies as they are requested by the runtime.

[lambdageek]

@lambdageek has an idea of creating an abstraction in the runtime that will allow to us to load only parts of the managed assemblies as they are requested by the runtime.

It's kind of a hacky idea that depends on two things:

1. A .NET assembly is basically 3 things: metadata tables, IL code, constant data and resources
2. zeroes compress better than actual data.

So what we could do is make 2 copies of the data for each assembly: one that has just the stuff we need at startup, with the other metadata rows and IL code zeroed out. And a second one that is just the original assembly. At startup we could bake in the special assembly and then load the normal one asynchronously and overwrite the image data in memory.

The only thing I'm not sure about is what we would do if the full assembly isn't available yet but some code needs it.

[maraf]

zeroes compress better than actual data.

You mean compress over the wire, right? The idea I was referring to was about saving max memory needed to load the assemblies. On desktop the runtime uses memory mapped files and we could simulate similar thing manually be loading only parts of the assemblies. Am I right?

The only thing I'm not sure about is what we would do if the full assembly isn't available yet but some code needs it.

In the context of nodejs/v8 the loading will be synchronous. So if the runtime will call into the javascript, we could supply the assembly data immediately.

[pavelsavara]

allow to us to load only parts of the managed assemblies as they are requested by the runtime.

@maraf could you please elaborate ? I don't get how is that useful in context of nodejs.

We would not be able to use memory mapped files into wasm memory unless we are willing to also implement native plugins into nodejs. At which point whole wasm architecture is kind of pointless and we could have normal x64 dotnet integrated with nodejs.

[maraf]

We would not be able to use memory mapped files into wasm memory unless we are willing to also implement native plugins into nodejs. At which point whole wasm architecture is kind of pointless and we could have normal x64 dotnet integrated with nodejs.

Okay. The parallel with memory mapped files was probably misleading. I wasn't suggesting implementing native nodejs plugin. If I remember correctly what we were talking about with @lambdageek, current approach and even the one with loading assemblies on demand from FS, requires loading whole assembly at once, but the runtime might need just piece of it. So I think the idea was to supply only pieces of assemblies as runtime needs them, instead of loading whole assembly at a time.