Using WebAssembly?

[facekapow]

V8 has support for WebAssembly, and supposedly has near-native speeds. Could we make use of this in runtime? Also, Wasm is hidden behind a flag, so is there any way to enable flags for V8 in runtime?

[iefserge]

Yes, we should be able to enable Wasm, I'm going to update V8 to the latest version and see if Wasm works. With Wasm runtime.js will no longer be limited to JavaScript, and things like crypto (libsodium) can be loaded as Wasm modules instead.

[piranna]

Yes, we should be able to enable Wasm, I'm going to update V8 to the
latest version and see if Wasm works. With Wasm runtime.js will no longer
be limited to JavaScript, and things like crypto (libsodium) can be loaded
as Wasm modules instead.

That would be cool! :-D

[RossComputerGuy]

That would be cool for BasicOS. Update on BasicOS: new homepage and I had to restart the project. There was too many errors.

[iefserge]

Got WebAssembly working using updated V8 (it still needs --expose-wasm which is disabled by default).

I'm trying to figure out a nice way to pass V8 flags. I'm thinking maybe read flags from v8.flags file in the root directory of the project. This will make it easy for each project to specify v8 flags it needs.

Wasm example looks like this

const fs = require('fs');
const buf = fs.readFileSync('add.wasm');

const addModule = Wasm.instantiateModule(buf);
console.log('wasm binary: add(1, 2) =', addModule.exports.add(1, 2));

asm.js -> wasm works too

function AsmModule() {
  'use asm';

  function add(a, b) {
    a = a | 0;
    b = b | 0;
    return (a + b) | 0;
  }

  return {add};
}

const addModuleFromAsm = Wasm.instantiateModuleFromAsm(AsmModule.toString());
console.log('wasm from asm: add(1, 2) =', addModuleFromAsm.add(1, 2));

[facekapow]

@iefserge Nice, I've got a little system built to test out runtime.js features and I've included a kernel with the flags enabled. One thing I've noticed is that emscripten-compiled WebAssembly takes a bit to load code with C headers, but at least twice as long to load C++ headers.

I like the idea of having custom flags in each project, but I wonder how this would be implemented? If they're set by the library after V8 is started, then it's dangerous. One way it could be done safely is for runtime-cli to read it from the package.json and embed it into the initrd header, then the kernel could read them and set them before initializing V8.

[iefserge]

@facekapow it would read file from initrd once during the startup. Shouldn't be an issue since initrd code is C++.
package.json solution is interesting too, but yeah it requires updating initrd format. How would this config look like in package.json?
I see you patched runtime to enable wasm, pretty cool :)

Edit: Actually runtime-cli can include any metadata as special files, so no initrd format updates are necessary.

[facekapow]

I think it'd be something like:

{
  "name": "my-pkg",
  "version": "1.0.0",
  "v8": {
    "flags": "--expose_wasm --harmony_async_await --other_flags"
  }
}

How does including metadata work? I quickly skimmed over the code to pack an initrd and to read it from the kernel and didn't see anything. Would it just be included as a regular file and read by the kernel?

Also, we could just parse the root package.json in the kernel using this little C++ JSON parser (or this other parser, focused on memory limited systems) and fetch the flags like that.

[iefserge]

There is a file type id, can use another id to include any metadata. https://github.com/runtimejs/runtime/blob/master/src/kernel/initrd.cc#L96

Anyway, you're right it might be easier to just parse JSON in C++, since we may have runtime.js flags there too at some point. Makes sense to group those?

{
  "runtime": {
    "enableProfiler": true,
    "enableWebWrokers": true,
    "v8flags": "--expose_wasm"
  }
}

[facekapow]

If we go the JSON route, in order to allow the field to be an object, runtime-module-loader would have to modified at line 129 and add something like:

  // ...
} else if (typeof parsed.runtime === 'object' && typeof parsed.runtime.main === 'string') {
  return parsed.runtime.main;
} else {
 // ...

And the corresponding code would need to be modified in js/__loader.js, but... it would have to wait until #120 merges (or doesn't), because again, would want to avoid any future merge conflicts.

Edit: and yes it makes sense group the options.

[iefserge]

Yeah sure, let's merge #120 first.

[kumavis]

i hunger for webassembly unikernels!

[yshemesh]

What is the state of using WASM in runtime.js? and why there is no place for an independent unikernel (not runtime.js) that only runs WASM?

[piranna]

What is the state of using WASM in runtime.js? and why there is no place for an independent unikernel (not runtime.js) that only runs WASM?

It could be feasable, there's already wasm VMs written in plain C, so it would be plainly trivial (but without a JIT compiler, fairly slow). There has been similar approachs in the past, for example Inferno OS with the dis assembler specification.

[RossComputerGuy]

Can a WebAssembly vm work?

[piranna]

Can a WebAssembly vm work?

It depends what do you want to achieve with it...

[RossComputerGuy]

If I were wanting to use it for adding numbers, it would work.

[piranna]

What do you mean by "adding numbers"?

[RossComputerGuy]

Just some WebAssembly tests and examples