Repository navigation
Docs cleanup - #286
Docs cleanup#286andreaTP wants to merge 6 commits into
Conversation
SIMD is interpreter-only: the bytecode compilers fail on v128, so the Quick Start requirement and the SIMD page overstated support. The compiler pages claimed parity with the interpreter's spec tests, which no longer holds. Also remove a dangling example reference in Linking, a license link pointing at a page without licenses, a copy-pasted stdout redirect, and release-time phrasing elsewhere. Add writing rules to the docs README.
Cut the method naming contract (it lives in the MethodPrefixer Javadoc), the three interpreter fallback samples, the Maven plugin help dump, the cache file layout, and the host function preamble. Each option is now a sentence or two and one builder sample.
Execution modes becomes the Compilation overview, CPU limits joins Security, Annotations joins Core Concepts next to host functions. The SIMD page is folded into the overview and the Rust example, a copy of the Memory page with a stale target triple, becomes a tip on that page. Old URLs redirect; approval files follow the moved pages.
One heading convention (frontmatter title, body sections from h2), one version placeholder, one set of names for the execution modes, shorter security admonitions that defer to the Security section, and a descriptive first sentence on every page for llms.txt. The Quick Start keeps one dependency snippet and defers to Installation. The Annotations type table now lists the string, Instance and Memory parameters the processor accepts.
Add a per-mode feature support table to the Compilation overview, a GC Types page showing applyWithRefs, WasmStruct and reference-taking host functions with a runnable corpus module, and a memory limits section on the Memory page linked from the security pages.
| This command generates static content into the `build` directory and can be served using any static contents hosting service. | ||
|
|
||
|
|
||
| ### Writing docs |
There was a problem hiding this comment.
this goes in Contributing.md
There was a problem hiding this comment.
Moved to CONTRIBUTING.md under "Writing docs" in c2aa2e5; the docs README now only points there.
|
|
||
| It's possible to provide a custom implementation of the entire Memory used by the Wasm module: | ||
| You can replace the `Memory` implementation backing a module through `withMemoryFactory`. | ||
| Workloads use memory in very different ways, so benchmark before changing it: |
There was a problem hiding this comment.
we had various conversations with andreas-karllson on PRs and Issues about the current status of memory.
We can look at the discussion and clearly state things here
There was a problem hiding this comment.
Rewritten in c2aa2e5 from the summary at the end of #224: a table comparing ByteBufferMemory (default, works everywhere, atomics always locked) and ByteArrayMemory (fastest for plain access on every JDK, lock-free atomics up to JDK 21 and locked from JDK 23, verified with jshell on 21/23/24/25), when atomics matter, and a pointer to Redline's native memory as the off-heap option that is not selectable through withMemoryFactory.
…ixes Move the docs writing rules to CONTRIBUTING.md and state the trade-offs of ByteBufferMemory and ByteArrayMemory as discussed in bytecodealliance#224. Clarify what memory limits cover (first memory only, no WasmGC allocations), fix the host function sample on the best practices page, and tidy wording and unused imports found in a self review.
I noticed the docs starting to suffer from organic growth, the level of detail was not balanced correctly, and overall it could be improved.
@andreas-karlsson asking your review for a second pair of eyes and because I'm touching a lot of sections we worked on together recently