[wasm] Document concurrent jump table patching

This adds some documentation why concurrently emitting code, patching
the jump table, and executing the jump table is safe.

R=ahaas@chromium.org
CC=​mstarzinger@chromium.org, joey.gouly@arm.com

Bug: v8:9477
Change-Id: Ibe295d538a1a330c6b1d94eb1f514d1078020754
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738856
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63137}

src/wasm/jump-table-assembler.h

@@ -37,6 +37,21 @@ namespace wasm {
 // The above illustrates jump table lines {Li} containing slots {Si} with each
 // line containing {n} slots and some padding {x} for alignment purposes.
 // Other jump tables are just consecutive.
+//
+// The main jump table will be patched concurrently while other threads execute
+// it. The code at the new target might also have been emitted concurrently, so
+// we need to ensure that there is proper synchronization between code emission,
+// jump table patching and code execution.
+// On Intel platforms, this all works out of the box because there is cache
+// coherency between i-cache and d-cache.
+// On ARM, it is safe because the i-cache flush after code emission executes an
+// "ic ivau" (Instruction Cache line Invalidate by Virtual Address to Point of
+// Unification), which broadcasts to all cores. A core which sees the jump table
+// update thus also sees the new code. Since the other core does not explicitly
+// execute an "isb" (Instruction Synchronization Barrier), it might still
+// execute the old code afterwards, which is no problem, since that code remains
+// available until it is garbage collected. Garbage collection itself is a
+// synchronization barrier though.
 class V8_EXPORT_PRIVATE JumpTableAssembler : public MacroAssembler {
  public:
   // Translate an offset into the continuous jump table to a jump table index.