Add JS Memory and Table API, support dynamic linking

[lukewagner]

This PR adds first-class WebAssembly.Memory and WebAssembly.Table objects along with the ability for modules to import and export any number of these from a given module. This generalizes the current linear memory / table design wherein a module cannot import linear memory and is limited to 1 linear memory / table for internal use and export. This PR also generalizes tables to be resizable (symmetric to memory) and parameterized by an element type which is, in the MVP, restricted to either "any callable function" or "any callable function with a given signature". Since there can be multiple memories/tables, the memory and table opcodes are given an index immediate.

With this PR, it should be possible to implement dynamic linking in a toolchain so this PR also updates DynamicLinking.md to explain how. See the note at the bottom of DynamicLinking.md for an obvious omission which we should consider adding (viz., constant-value imports/exports, which would be used to position data segments and function-table-elements at load time).

This PR also punts on the precise way to describe a signature in JS when calling the WebAssembly.Table constructor, saving that for its own PR where we can bikeshed; see TODO in ToTypeDescriptor.

[kripken]

I am very excited about Tables! :) That's all we need for some useful forms of dynamic linking.

But I am worried about Memories. First, a concern here is a binary code size increase due to adding an immediate to loads and stores, which are very common (those two are over 13% of opcodes, and adding one byte for each leads to a 6% increase in binary size). Second, imported memories are not strictly needed for dynamic linking; emscripten supports dlopen() and shared libraries right now without multiple memories, for example. The cost is copying the memory init during startup, but it's not that bad - is there some other benefit to multiple Memories that I am missing?

Overall, Tables and Memories seem like separate features. Perhaps it makes sense to discuss them separately?

[lukewagner]

With partial specialization of immediates in the opcode table, then the 1 opcode entry (per load/store op) that would already be allocated to partially specialize natural alignment would also specify the heap index, so this doesn't necessarily impact code size. I expect we'll discuss this PR for a while, during which time we can figure out opcode tables and have more concrete details, but I wouldn't argue against this feature just for presumed binary size reasons now.

Multiple memories are basically an obvious generalization that I think practically every person in the wasm group has independently proposed over the last year. The use cases involve some of the ones given for having memory-imports at all in previous discussions: when implementing a VM, you could have separate host and guest memories. Separate memories might also be a good tool to avoid OOMs due to 32-bit fragmentation (by splitting 1 huge contiguous range into multiple) and could be used by special subsystems like file i/o which can statically separate where different data lives. Lastly, in the future, we might allow imports of other, non-WebAssembly.Memory objects (e.g., (Shared)ArrayBuffer, something to alias the bits of a <canvas>, ...), allowing fast and flexible access to these via memory operations.

[ghost]

Seems a small step to allow a table specialized to a particular function signature, thus allowing instances of call_table to do validation checks when compiling or loading and thus avoid dynamic signature checks. Could just generalize the current function table, adding a signature field that has a wild value when not specialized, and allow multiple function tables in the MVP.

[jfbastien]

I'm quite a fan of memories, it'll also make it easier to separate stuff out of the current single heap, such as the user stack, reducing user-side bugs / security issues, and it'll potentially also reduce fragmentation if the compiler is clever about certain things (I think that'll be a longer term gain).

[ghost]

Sorry, I don't understand what the "elements section" contains? What are the "element segments"? Are they sub-ranges of table index spaces? Or is this a section with all the elements from all tables with the elements grouped into ranges as in the tables? Why is this needed and how is it to be used?

[lukewagner]

Basically, what this PR is doing is splitting 1 section (the table section) into two halves: two ways to "get" a table (import or define), and 1 way to stick your module's table elements into any table you "got". The best way to think about this is as symmetric to memory imports/definitions and data segments. I rewrote this section to be more clear, though.

[ghost]

@jfbastien The stack is a high frequency access area, and it's going to degrade the file size to be flipping between opcodes with different segments, so developers are not going be a 'fans' of code using that style. If developers want a bounds checked stack then they can emit explicit checks - this use case does not need explicit support by wasm.

Bounds checking lots of small segments would be hard to optimize. Each is going to need a large chunks of VM for a memory protection scheme, so they would need large base offsets so either use a lot of immediate code memory or increase register pressure.

I doubt the 'fragmentation' benefits would be realized in most cases anyway as the main use of these segments would likely be for small areas of memory per module and modules will be using global memory for general use.

Lastly, C code is generally not written in a segmented memory model these days. I recall the old days with all the different memory models, and I would not wish this on the next generation of web developers.

[kripken]

@lukewagner: Agreed that we can keep code size issues for later in the discussion of this PR.

Regarding the use cases presented by you and @jfbastien:

1. They could also be done by a GC reference to an ArrayBuffer, which is a feature on the roadmap anyhow. There may be a perf difference, but for several of those use cases it probably wouldn't matter anyhow (e.g., for a separate file I/O space, emscripten has an option for that now with the filesystem stored out of main memory, and it works reasonably well). For others, we should measure.
2. Using multiple memory spaces in a C or C++ program is not going to directly work (since each pointer needs to be able to refer to anything), so I don't see how the user stack as suggested could be done in another space? This feature will be very limited in scope.

Given those two, I don't see Memories as well-motivated, certainly not for the MVP - in what way are we not viable otherwise?

[lukewagner]

@kripken C++ could be given access to multiple memories through address space annotations. This prohibits use of more than 1 general purpose memory (whose pointers could escape "into the wild", where static address space is lost), so unfortunately, I don't think this could be used for, e.g., the user stack. But this could be used by self-contained subsystems, like the in-memory file-system and interfacing with APIs in the future. Using GC references is a further generalization but would lose some optimization potential.

As I said in a comment above, if we thought this would be a major complexity burden, we could save ourselves some time in the MVP by constraining to 0..1. But given the work I think we all will want to do to support better code sharing (this type of stuff), I think the work required to support N heaps won't be too bad. Even if we constrain to 0..1 in the MVP, though, I'd like to have the design for N understood/documented since it's very easy to make a design that bakes in assumptions of 1 and would then require duplicating a bunch of things.

[lukewagner]

(Interested to hear what other engines think about the work required for multiple memories, of course; constraining to 0..1 is certainly an acceptable option if it looked prohibitive.)

[rossberg]

I wonder whether a call_table operator still is the right thing to have at this point. If we plan to add other table entry types in the future, wouldn't it make more sense to decompose it into get_table and call_ptr? We want to add function pointers anyway, so maybe the logical step would be to do that now, and avoid a redundant special case?

[lukewagner]

@rossberg-chromium That's an interesting idea, but if we add function pointers as a real value type, it seems like we'll end up needing full GC safe-point support which I've been enjoying not having to mess with. I also wonder if we might accidentally rush the feature (b/c we only need this sliver of it) in a way that we might regret if we waited until we understood the whole GC problem domain. Lastly, I'm interested in having this option that, even when we have first-class references, allowing wasm to only manipulate those references indirectly (through indices into tables) in a way that allows a wasm worker (or even webapp) to not need to create a GC heap or any of the related machinery; from this POV, you want the ability to pass in the index to the thing you want to operate on, which lines up nicely with call_table.

[rossberg]

@lukewagner, hm, I was referring to plain, C-style function pointers, not closures. How would that involve GC?

[ghost]

fwiw I think there should be a distinct variant of wasm that works without garbage collection, even after the support for GC objects has been added. It could be a variant that is declared and allows the runtime to optimize for this. Threads running such variants could run in parallel with garbage collection on other threads serving different instances.

@rossberg-chromium Some examples of call_ptr might help? If they are just C function pointers then this use case seems to be handled in wasm by call_indirect or call_table. If they are boxed opaque objects then are they a small set of pinned objects not subject to GC?

@lukewagner If external GC objects can be referenced by an index then the external GC needs to know about these references. It might be more generally useful to be able to import boxed objects defined to be pinned in memory and reference counted, so that the wasm thread need not be concerned about them being garbage collected yet still be able to pass them around as boxed objects.

[rossberg]

@JSStats, very straightforward: introduce a new value type, say, funcptr; values can be created by an operator (addressof <funcid>), and consumed by the call operator (call_ptr <typeid> <ptr> <arg>*).

Moreover, you can introduce typed variants, i.e., value types (funcptr <typeid>), where the call operator does not need to perform any runtime check.

In fact, I would prefer to avoid misleading terminology like "pointer" and "address" for this, since these are opaque references. That's how they differ from the table: the only reason we need that is to compile C, where function pointers have to be numeric, because (a) C allows stupid casts, and (b) you need to be able to store them in linear memory. For other purposes, this indirection is completely unnecessary.

[ghost]

@rossberg-chromium It appears that without involving garbage collection that these funcptrs would need to be interned objects anyway, so could be referenced by an index, so it's not clear what has been gained, and these objects could not be stored in the linear memory which is a loss, so for a wasm without garbage collection they appear to be a net loss?

This PR proposes typed function index spaces to avoid runtime signature checks.

Being able to store function references in linear memory seems a very compelling use case to me.

[rossberg]

@JSStats, no interned objects needed, just plain code addresses.

[titzer]

Supports isn't really the right term here. It's more "enables" or "allows", since WebAssembly itself only provides mechanisms, and the rest is done in user space.

[lukewagner]

Agreed, changed.

[titzer]

I'm not sold on multiple memories, or why we actually want them quite yet. It's a tempting generalization, but I don't see the problem they actually solve. Actually, I think they create a far worse problem providing a statically segmented address space as the programming model. Would we want dynamically indexed memories in the future? Then why the restriction to static indexing now?

There are larger questions we need to discuss here, like what will the role of memory be in the future programming model, which has yet to really emerge. In particular, a future with managed data extensions make adding more generality with multiple memories less important, and tantalizingly suggest that memory or memories in the future will be relegated to IO duties rather than the main program storage.

[ghost]

@rossberg-chromium Thank you, I guess raw unboxed code addresses could be passed around and stored in local variables just as a floating point numbers are, and I guess these could be prohibited from escaping or could be boxed if they do escape and perhaps then qualified by the instance too. But the inability to store them in the linear memory is still a show stopper.

[rossberg]

@JSStats, for that we continue to have tables. But they're only needed in some cases. And it's pretty clear that we will eventually get other opaque types that cannot be stored in linear memory anyway.

[titzer]

One criteria that was considered important for the current design of function pointers was to avoid having local types for function pointers, because we weren't (and IMO still aren't) ready to cross that boundary for MVP.

[lukewagner]

@titzer Assuming we get a first-class Memory references some time in the future (by which I mean: that you could store in a local and access dynamically), I don't see the fundamental difference/cost (performance, implementation, complexity) with allowing multiple memory imports. It seems unnecessarily irregular if we have multiple imports/exports of functions, tables (and, in the future: values, global variables, thread-local variables, ...) but only single imports/exports of memories. It begs the question: Why not memory too?

As for "why the static restriction now?" I think it's the same answer for tables (assuming we get first-class Table references too): because it allows you to declaratively compose modules (via imports/exports) that share these things. E.g., if one has a worker containing only modules that import/export memory/tables, and therefore don't pass around first-class GC references, you don't need a GC in that worker (and you can know this a priori).

Again, if we think it causes undue impl burden in the MVP, I'd be fine to simply constrain the number of memory imports to <=1, as we've done with the number of return types in signatures. I'm not trying to create more MVP work; I'm trying to avoid long-term irregularity that isn't pragmatically necessary.

[ghost]

@lukewagner But what is the benefit of being able 'to declaratively compose modules'? The claimed reasons seems to be that 'you don't need a GC in that worker', but having boxed object and garbage collection seem somewhat orthogonal, and a worker could accept a boxed buffer reference without having to worry about garbage collection but would just need some guarantees that the object is not going to be moved or reclaimed which could be a burden for the supplier of this object and not the worker.

Practically most implementations will need to keep these buffer bases in memory and load them as needed whether they are defined declaratively or dynamically, so what has been achieved? Perhaps 32 bit x86 could be the exception where it might be possible to bake in the bases into the instruction immediate offsets.

If there is a benefit then perhaps it is something else? For example, knowing the size of a buffer at compile time might help optimize accesses. Knowing that these buffers are in an area of VM using memory protection to assist avoiding bounds checks might help, but then perhaps there could just be a dynamic buffer type that has these properties too, to have buffer types with constraints on their size and with different memory protection guard zones etc.