Instantiate loads modules for every instance about jco

[guybedford]

Firstly note you can just write compileCore to cache fetch (which you probably should).

I'd be open to this, but as a variation of the --instantiation flag to indicate it's a third virtualization level sitting in between full virtualization and host-level resolution.

The current instantiation in this general form doesn't assume the location of Wasm modules on the filesystem or top-level await. In theory by not relying on Promise.all we also allow bindings work to continue even when some modules are still being compiled.

Perhaps --instantiation=full is used to distinguish the current form, or something similar? Would you be interested in working on a PR?

[kajacx]

Firstly note you can just write compileCore to cache fetch (which you probably should).

Good idea. This would load and compile the cores "lazily" on the first instantiate, which has it's advantages, but might not always be desired.

I am still "stuck" in the "Component::new"/Module::new and "component.instantiate"/Module.instantiate being 2 separate things, but I guess I could do something like this:

export function preLoadCores(compileCore) {
  return Promise.all([
    compileCore('component.core.wasm'),
    compileCore('component.core2.wasm'),
    compileCore('component.core3.wasm'),
  ]);
}

export async function instantiate(compileCore, imports, instantiateCore = WebAssembly.instantiate) {
  const module0 = compileCore('component.core.wasm');
  const module1 = compileCore('component.core2.wasm');
  const module2 = compileCore('component.core3.wasm');
  // ...
}

The current instantiation in this general form doesn't assume the location of Wasm modules on the filesystem

That's true, the module bytes could be in-memory, which they are in my use-case

... or top-level await

I am not familiar enough with how JS modules are loaded to understand the pros and cons of top-level awaits.

One thing I will not though is that the exports without instantiation mode are kind of messed up.

You get an $init object that you are supposed to await, and the exported functions, which you should call after awaiting the init object, but the exported function are not the result of awaiting the init object, you just get and can call them "wrongly".

I understand that this is workaround for situation where the top-level await will not be awaited, but it's still kind of messed up.

... to indicate it's a third virtualization level sitting in between full virtualization and host-level resolution.

I will admit I have no idea what that means.

In theory by not relying on Promise.all we also allow bindings work to continue even when some modules are still being compiled.

That's a good point. I added the // TODO: should be Promise.all mostly because in the proof of concept code the cores were being loaded sequentially instead of simultaneously, which Promise.all would solve.

Perhaps --instantiation=full is used to distinguish the current form, or something similar? Would you be interested in working on a PR?

Maybe, what I would be interested in is exporting two separate functions:

• compile that compiles the cores and returns the instantiate function. This function can take compileCore as an argument, but it would be even better if it was an optional argument and the default would be to take the cores from the same directory as the .js script is it, the same way it is done without the instantiation flag.
• instantiate function that works with the already-compiled cores. You cannot call instantiate without calling calling compile first, because you get the instantiate function as a result of the compile function.

If this workflow is something you would be willing to merge (enabled with the --instantiation=full flag, let's say), then I can work on it.

[guybedford]

Your suggestions sounds fairly sensible to me. I would still prefer that compile be optional though and that just-in-time compilation can still be used by default as it is currently structured. So that instead of this being an explicit compile "step", it is an optional precompile step.

Something like:

let compileCache = {};
const defaultCompileCore = name => compileCache[name] || (compileCache[name] = fetchCompile(name));

async function fetchCompile (name) {
  // ... standard implementation ...
}

export const precompile = (compileCore = defaultCompileCore) => Promise.all([
  compileCore('name1.core.wasm'),
  // ...
]);

export async function instantiate(imports, compileCore = defaultCompileCore, instantiateCore = WebAssembly.instantiate, compileCore = ) {
  // .. compileCore interleaving remains ..
  const modulen = await compileCore('componentn.core.wasm');
}

Does the above work for you? If so, in this framing we don't even need another mode for it and could make it the default, possibly with an optional --no-precompile flag or something to disable it?

[kajacx]

The argument order in instantiate changed, but that can be fixed with something like

export async function instantiate(compileCore, imports, instantiateCore = WebAssembly.instantiate) {
  compileCore = compileCore || defaultCompileCore,
  // .. compileCore interleaving remains ..
  const modulen = await compileCore('componentn.core.wasm');
}

Now it's slightly confusing that the first argument is optional, but changing the argument order is a breaking change.

I could start working on a PR, but currently I have other things I want to finish first.

[guybedford]

@kajacx JCO is currently under active development so it's fine to make breaking changes.

[guybedford]

We almost got to a concrete proposal here, which I'd be very happy to land in this project, but short of that work actually happening - since this is in theory purely ergonomic and neither a feature nor a bug, closing for now.