Fix typos in Markdown files

Clean up misspellings via codespell.

Author: algonell

compiler/docs/Debugging.md

@@ -78,7 +78,7 @@ obtained with `-XX:+JVMCIPrintProperties -Djdk.graal.PrintPropertiesAll=true`.
 The compiler supports metrics in the form of counters, timers and memory trackers.
 Each metric has a unique name. Metrics are collected per-compilation.
 At shutdown, they are aggregated across all compilations and reported to the console.
-This ouput can be redirected to a file via the `-Djdk.graal.AggregatedMetricsFile` option.
+This output can be redirected to a file via the `-Djdk.graal.AggregatedMetricsFile` option.
 
 To list the per-compilation metrics, use the `-Djdk.graal.MetricsFile` option. If not specified,
 per-compilation metrics are not reported.

docs/graalvm-as-a-platform/implement-language.md

@@ -136,7 +136,7 @@ gu -L install /path/to/sl-component.jar
 A language built with Truffle can be AOT compiled using [Native Image](../reference-manual/native-image/README.md).
 Running `mvn package` in the SimpleLanguage directory also builds a `slnative` executable in the `native` directory.
 This executable is the full SimpleLanguage implementation as a single native application, and has no need for GraalVM in order to execute SimpleLanguage code.
-Besides this, a big advantage of using the native executable when compared to running on GraalVM is the greatly faster startup time as shown bellow:
+Besides this, a big advantage of using the native executable when compared to running on GraalVM is the greatly faster startup time as shown below:
 ```shell
 time ./sl language/tests/HelloWorld.sl
 == running on org.graalvm.polyglot.Engine@2db0f6b2

docs/reference-manual/llvm/Compiling.md

@@ -7,7 +7,7 @@ permalink: /reference-manual/llvm/Compiling/
 # Compiling to LLVM Bitcode
 
 GraalVM can execute C/C++, Rust, and other languages that can be compiled to LLVM bitcode.
-As the first step, you have to compile a program to LLVM bitcode using some LLVM compiler front end, for example, `clang` for C and C++, `rust` for the Rust programing language, etc.
+As the first step, you have to compile a program to LLVM bitcode using some LLVM compiler front end, for example, `clang` for C and C++, `rust` for the Rust programming language, etc.
 
 ## File Format
 

docs/reference-manual/native-image/DebugInfo.md

@@ -833,7 +833,7 @@ inlined compiled method code as well as mappings from code addresses
 to the corresponding source files and lines.
 `perf` and `valgrind` are able to use this information for some of
 their recording and reporting operations.
-For example, `perf report` is able to associate code adresses sampled
+For example, `perf report` is able to associate code addresses sampled
 during a `perf record` session with Java methods and print the
 DWARF-derived method name for the method in its output histogram.
 

docs/tools/insight/Insight-Manual.md

@@ -672,7 +672,7 @@ The `returnValue` function is always available on the provided `ctx` object, but
 
 If you ask whether GraalVM Insight causes any performance overhead when the scripts are applied, the answer is "No" or "Minimal".
 The overhead depends on what your scripts do.
-When they add and spread complex computations all around your code base, then the price for the computation will be payed.
+When they add and spread complex computations all around your code base, then the price for the computation will be paid.
 However, that would be overhead of your code, not of the instrumentation.
 Using a simple _function-count.js_ script, measure overhead.
 

docs/tools/insight/README.md

@@ -210,7 +210,7 @@ That provides ultimate insights into execution and behavior of one's application
 
 To continue learning and deep dive into GraalVM Insight, proceed to the [Insight Manual](Insight-Manual.md) which starts with an obligatory _HelloWorld_ example and then demonstrates more challenging tasks.
 
-### Embeddeding GraalVM Insight into Applications
+### Embedding GraalVM Insight into Applications
 
 GraalVM languages (languages implemented with the Truffle framework) can be embedded into custom applications via [Polyglot Context API](https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Context.html).
 GraalVM Insight can also be controlled via the same API.

espresso/docs/continuations.md

@@ -132,7 +132,7 @@ There are special situations in which a call to `suspend` may fail with `Illegal
 - If in between the call to `resume` and `suspend` any of the following holds:
     - A lock is held (this may be an object monitor through the `MONITORENTER` bytecode, or even
       a `java.util.concurrent.locks.ReentrantLock`).
-    - There is a non-java frame on the stack (this could be a `native` method, or even a VM instrinsic).
+    - There is a non-java frame on the stack (this could be a `native` method, or even a VM intrinsic).
 
 Furthermore, there is currently no support for continuation-in-continuation.
 

espresso/docs/how-espresso-works.md

@@ -176,7 +176,7 @@ a series of slots stored on the host stack, or when _materialized_, the frame is
 languages these slots are strongly typed and correspond to the base Java type system with ints, booleans, longs and
 object references etc. Espresso however uses Truffle's _static slots_, which are (somewhat confusingly) both typed and
 untyped at the same time. The Truffle `Frame` interface has an API for reading and writing to static slots which
-distinguishes betwen primitive types (`get/setObjectStatic`, `get/setLongStatic` etc), but the actual primitive type of
+distinguishes between primitive types (`get/setObjectStatic`, `get/setLongStatic` etc), but the actual primitive type of
 a static slot is tracked only when assertions are enabled i.e. in debug mode. You can see some of this code in Truffle's
 `FrameWithoutBoxing` class. In normal execution the slot types are marked only as being "static". This is OK because
 Java bytecode implicitly types stack slots. The types aren't recorded in the bytecode itself, but can be recovered using

sdk/CHANGELOG.md

@@ -163,7 +163,7 @@ the close operation throws a [`PolyglotException`](https://www.graalvm.org/sdk/j
 
 ## Version 22.0.0
 * (GR-31170) Native Image API: Added `WINDOWS_AARCH64` Platform.
-* (GR-33657) Native Image API: Added `CEntryPoint#include` attribute which can be used to controll if the entry point should be automatically added to the shared library.
+* (GR-33657) Native Image API: Added `CEntryPoint#include` attribute which can be used to control if the entry point should be automatically added to the shared library.
 * (GR-22699)(EE-only) Added the ability to spawn a native-image isolate for a each `Engine` or `Context` by calling `Context.Builder.option("engine.SpawnIsolate", "true")`.  This enables heap isolation between the host and guest applications. Using isolates improves security, startup and warmup time of polyglot languages. In this mode, calls between host and guest are more costly as they need to cross a native boundary. It is recommended to use the `HostAccess.SCOPED` policy with this mode to avoid strong cyclic references between host and guest. This mode is experimental in this release and only supported for a limited set of languages. 
 
 ## Version 21.3.0

sdk/mx.sdk/vm/windows.md

@@ -58,7 +58,7 @@ to work.
 ## Testing
 
 A primitive way to test the windows script is to copy the template to a file
-named `test.cmd`, and make a couple temporary adjustements:
+named `test.cmd`, and make a couple temporary adjustments:
 
 - Prefix the final command invocation with `echo`.
 - Escape all substitution tags that live within strings with `^`. e.g.