Postpone adding globals until dynamic linking

[lukewagner]

Split off from #139: I was thinking that perhaps globals should be removed from the MVP and instead go in with the dynamic linking feature. The reasoning is that, until we have to worry about dynamic linking, we can simply place globals in the heap and use compiler-chosen static offsets; indeed this is what we'll need to do anyway for any global whose address is taken (and what Emscripten does for most globals anyway, to avoid JS engine number-of-closure-variable limitations). Technically, globals have the advantage that they can't be aliased by loads/stores, but I don't expect this will win much in practice (esp. assuming a C++ compiler has already optimized the code).

Thinking forward to dynamic linking: since we have to deal with aliased globals anyway, it seems simpler and more orthogonal (not requiring a separate set of LoadGlobal/StoreGlobal ops) to have globals declare immutable pointers (i.e., integers) that would then be used as arguments to plain LoadHeap/StoreHeap ops (so LoadGlobal(a) => LoadHeap(Global(a)) where Global(a) is a const-expr of int32/int64 type). Even trivial backends should have no problem eliminating bounds checks.

With this strategy, the question is of course where the memory pointed to by the global pointers comes from: the engine has no knowledge of how the memory in the [0, sbrk-max) range is being used by malloc et al. There is a lot of room for design here, but I think roughly what we need to do is let the application allocate the data and give it to the engine (either directly or by registering a global data allocator with the runtime). The important thing is that we keep allocation (and addresses) deterministic and under application control so that applications can do smart things with their address space (shadow stacks, emulating MAP_FIXED, etc).

Lastly, I think this same strategy applies to TLS variables: TLS variables would be pointers into the heap and we'd need a way for the user application to allocate the memory pointed to by these TLS variables (when new threads are created or for each thread when new modules are loaded with TLS variables; that's why I feel like these two issues are related and can have symmetric solutions).

[jfbastien]

"globals declare immutable pointers (i.e., integers)" sounds an awful lot like a relocation!
Putting my TLS usecases link here.

This proposal sgtm.

[kripken]

How would this work in the polyfill?

[lukewagner]

Since this would only come with dynamic linking:

1. for load-time dynamic linking, we can convert global variables into literal integers (assuming the polyfill slurps all the dynamically-linked modules into one asm.js module)
2. for runtime-dynamic linking, I don't think we have an efficient polyfill option anyway; but anyhow global variables can turn into integer global variables in asm.js.

[kripken]

Sorry, I meant, how would existing asm.js code (no linking) be polyfillable, without globals (which are in asm.js)?

[lukewagner]

Well, asm.js could still use asm.js. Unless you're asking about asm.js->wasm->asm.js; that seems harder (I can imagine hacky solutions, though, especially if Emscripten were to participate), but that seems ok.

[kripken]

Was that not the point of your polyfill prototype, asm.js=>wasm=>asm.js? I guess I am surprised to hear that is being given up on? This is the first feature that seems to break that.

[lukewagner]

Yeah, that was useful for experimentation purposes, but I don't think it should constrain the overall design.

[kripken]

It will also be a limitation on using emscripten to emit wasm - as we were intending to go through asm.js in some parts of our pipeline (I discussed details of that at length with @sunfishcode). This would appear to require a complete rethinking of that strategy. I'll think more about that, but in general I think this aspect - breaking asm=>wasm - is something we need to discuss and consider carefully. I was operating under that assumption, removing it would be a big change.

[lukewagner]

For Emscripten's case can't you just control codegen not to emit globals (to use heap instead, as is already supported)?

[kripken]

That is what I am thinking about, sure, but it isn't quite so simple. Not all the globals come from compiled code.

[lukewagner]

In the limit, the polyfill can always transform reads/writes to globals to FFI calls that use outside-asm.js storage. I don't think this corner case should influence the much-longer-lived standard, though.

[kripken]

In general I agree the polyfill should not influence long-term plans, and good point that ffis can be a non-performant polyfill, if we need that.

Anyhow, getting back to the topic here: I think globals are a very convenient feature for human beings. Just like having the != operation. Still matters even if generally compilers emit wasm code; humans still do View Source it, debug it, etc. To be concrete, a very important global is the C stack pointer, and what is better of the following:

void withGlobals() {
  i32 s = sp;
  i32 buffer = s;
  i32 more = s + 8;
  sp = s + 16;
  // ..
  operate(buffer, more);
  // ..
  sp = s;
}

void withoutGlobals() {
  i32 s = load32(1024);
  i32 buffer = s;
  i32 more = s + 8;
  store32(1024, s + 16);
  // ..
  operate(buffer, more);
  // ..
  store32(1024, s);
}

The stack pointer is an extremely common thing, appearing at the beginning and end of most functions (and also sometimes in the middle). Without globals, our View Source suffers significantly, and in particular regresses significantly compared to asm.js (which is a shame since we win in so many other ways!). And with decreases in source readability come downsides in debuggability, understanding performance profiles, etc.

[lukewagner]

With the above proposal, sp is just replaced with load(sp) and store(sp, s) (assuming we have symbol data, which is the assumption of your snippets above) which seems just as readable and is more honest about what's happening.