T0b1/wasmtime
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix a few typos in the architecture doc (#3054)

Browse Source
This commit is contained in:
Benjamin Bouvier
2021-07-02 20:09:58 +02:00
committed by GitHub
parent 518ce2512d
commit 93b7cdd6a2
1 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/contributing-architecture.md
View File

@@ -165,7 +165,7 @@ Compilation is roughly broken down into a few phases:
(`wasmtime_environ::Module`), compiled JIT code (stored as an ELF image), and
miscellaneous other information about functions such as platform-agnostic
unwinding information, per-function trap tables (indicating which JIT
instructions can trap and what the trpa means), per-function address maps
instructions can trap and what the trap means), per-function address maps
(mapping from JIT addresses back to wasm offsets), and debug information
(parsed from DWARF information in the wasm module). These results are inert
and can't actually be executed, but they're appropriate at this point to
@@ -224,8 +224,8 @@ that specific case because we don't know the ABI of the target function the
trampoline (with a known ABI) is used and has all the parameters/results passed
through the stack.
Another point of note is that trampolines not deduplicated at this time. Each
compiled module contains its own set of trampolines, and if two compiled
Another point of note is that trampolines are not deduplicated at this time.
Each compiled module contains its own set of trampolines, and if two compiled
modules have the same types then they'll have different copies of the same
trampoline.
@@ -396,12 +396,12 @@ memory64 proposal from upstream WebAssembly yet.
The defaults for Wasmtime on 64-bit platforms are:
* 4gb static maximum size (meaning all memories are static)
* 2gb static guard size (meaning all loads/stores with less than 2gb offset
* 4GB static maximum size (meaning all memories are static)
* 2GB static guard size (meaning all loads/stores with less than 2GB offset
don't need bounds checks)
* Guard pages before linear memory are enabled.
Altogether this means that linear memories result in an 8gb virtual address
Altogether this means that linear memories result in an 8GB virtual address
space reservation by default in Wasmtime. With the pooling allocator where we
know that linear memories are contiguous this results in a 6GB reservation per
memory because the guard region after one memory is the guard region before the
@@ -424,10 +424,10 @@ within, they're simply assumed to be valid for as long as the table is in use.
For tables of `externref` the story is more complicated. The `VMExternRef` is a
version of `Arc<dyn Any>` but specialized in Wasmtime so JIT code knows where
the offset of the reference count field to directly manipulate it. Furthermore
tables of `externref` values need to manage the reference count field
themselves, since the pointer stored in the table is required to have a strong
reference count allocated to it.
the offset of the reference count field to directly manipulate it is.
Furthermore tables of `externref` values need to manage the reference count
field themselves, since the pointer stored in the table is required to have a
strong reference count allocated to it.
## GC and `externref`