4 ms·

In my opinion this is a fascinating approach, and it may end up transforming our industry. But the main question I've had is how big the overhead is, specifica

• SkyMarshal 7y ago
  I’d rather start with something provably secure and slower, and then optimize its performance and features over future iterations and versions. Starting with speed and trying patch in security doesn’t seem to make things actually secure.
• JoshTriplett 7y ago
  > specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. We're working on that. We want to make it possible for modules to share memory in a controlled way, without giving access to their entire address space.
  • azakai 7y ago
    Interesting! Is that written up somewhere public?
    • JoshTriplett 7y ago
      Some of it; see https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type... for the starting point that this will be based on.
      • azakai 7y ago
        Oh, where? I don't think I see anything about controlled memory sharing there, but I guess I missed it. Which section is it in?
        • JoshTriplett 7y ago
          It isn't yet, that work is still in progress. WIT is just the starting point that this would be based on. (Sorry for the lack of more concrete information, documentation is still in progress.)
          • azakai 7y ago
            I see, thanks. Curious to learn more when it is public.
  • BubRoss 7y ago
    Shared memory can certainly do this. Even separate processes can use shared memory to communicate lock free using atomics. Other than that, I wonder if nested page tables that are normally used for virtualization can be used to separate address spaces within a process.
• Arnavion 7y ago
  >specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. It is possible today to have modules import memory from the host, which means the host can provide the same imported memory to multiple modules. Then modules can pass pointers to each other without needing any memcpys. It does require the modules to not tread on each other though, such as by requiring them to have distinct static offsets (poor man's linking), or by requiring them to be PIC / compiled with relocation info so that they can be relinked by the host loader. It doesn't seem to me from reading TFA that this is going away, merely that there are planning to add alternatives to make it more fine-grained.
  • azakai 7y ago
    It is possible to share memory in wasm today, yes (we use that to optimize wasm/JS interaction, and wasm/wasm dynamic linking) - and that won't go away, it's a core feature of wasm, you're right. But the specific approach in this article disallows that. The article does mention a possible future extension of multiple wasm modules in a single nanoprocess (the section with "allowing native-style dynamic linking"), and JoshTriplett mentions in another comment some future ideas of sharing parts of memory but not all. Those things will compromise the strict initial requirement of no shared memory, and improve performance. Those are the interesting questions for me - is not sharing memory too much overhead, and if it is, is there a way to relax that which preserves enough security with enough performance.
    • luke_wagner 7y ago
      To the question of "how would dynamic linking work in the future", as already stated in the article, a nanoprocess doesn't need to correspond 1:1 to a wasm module/instance. Rather, N wasm instances can share a single wasm memory to collectively represent a single nanoprocess. From an external point of view, whether a nanoprocess is implemented as 1 or N instances wouldn't be visible -- it's an impl detail -- and the memory is (still) encapsulated by the nanoprocess. Thus, there is a two-level hierarchy of: a graph of shared-nothing-linked nanoprocesses each containing a graph of shared-everything wasm instances. There's still a lot more details to figure out, of course, but that's true for wasm dynamic (shared-everything) linking in general.
• AnIdiotOnTheNet 7y ago
  Last I checked WebAssembly still didn't have a way of actually freeing memory it has allocated either.
  • thrax 7y ago
    You give it a heap. It doesn't allocate memory. It may allocate within its own heap, using whatever allocator/gc strategy it inherits from it's host language.
    • kllrnohj 7y ago
      Which means it can't free. But that's also not accurate, anyway, there's a brk() method to grow the heap. Which is such a bad starting point for a new runtime.
      • saagarjha 7y ago
        Would it be impossible to implement mmap and sbrk in the runtime?
        • kllrnohj 7y ago
          mmap is arguably the only thing it should have had in the first place. brk/sbrk is fairly dead.
          • saagarjha 7y ago
            $ strace /bin/ls 2>&1 | grep brk brk(NULL) = 0x55fb032b3000 brk(NULL) = 0x55fb032b3000 brk(0x55fb032d4000) = 0x55fb032d4000
            • wahern 7y ago
              $ ktrace /bin/ls >/dev/null $ kdump | grep brk | wc -l 0 $ kdump | grep mmap | wc -l 130 glibc, musl, and jemalloc got the memo, they just couldn't be bothered to stop using brk by default. They're all capable of using mmap exclusively, however, because whether or not brk is actually dead, there's long been consensus that mmap is the better abstraction on balance, particularly given the benefit of ASLR. So there's little reason to support brk instead of mmap for compatibility. Presumably it was chosen for the convenience of WebAssembly implementations--contiguous, flat memory is a great simplifier of VM, JIT, and even traditional AoT architectures.