If I'm reading this correctly, they are not planning to add a JIT but just the features required for implementing your own:
WebAssembly should support:
Producing a dynamic library and loading it into the current WebAssembly module.
Define lighter-weight mechanisms, such as the ability to add a function to an existing module.
Support explicitly patchable constructs within functions to allow for very fine-grained JIT-compilation. This includes:
Code patching for polymorphic inline caching;
Call patching to chain JIT-compiled functions together;
Temporary halt-insertion within functions, to trap if a function start executing while a JIT-compiler's runtime is performing operations dangerous to that function.
Provide JITs access to profile feedback for their JIT-compiled code.
Code unloading capabilities, especially in the context of code garbage collection and defragmentation.
Re:From Asm.js to WebAssembly
by BrendanEich on Wednesday June 17, 2015 @08:02PM
(#9736027)
Right, because wasm is for AOT (ahead of time) languages first. To support dynamic languages that don't map to JS well, the future extensions including JITting wasm will be needed.
The design documents clearly state that WASM is intended to be a compilation target for C-like languages, and in the future may also contain a GC and an optimizing JIT.
Languages requiring a GC and/or not amenable to AOT optimization should -- at least for the time being -- continue to target JS as a compilation target (or implement their own runtime in a C-like language and embed it in WASM).