chore: fix some comments (#105504)

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

docs/design/coreclr/jit/profile-count-reconstruction.md

@@ -111,7 +111,7 @@ So solution techniques that can leverage sparseness are of particular interest.
 
 Note the matrix $\boldsymbol I - \boldsymbol P$ has non-negative diagonal elements and negative non-diagonal elements, since all entries of $\boldsymbol P$ are in the range [0,1].
 
-If we further restrict ourselves to the case where $p_{i,i} \lt 1$ (meaning there are are no infinite self-loops) then all the diagonal entries are positive and the matrix has an inverse with no negative elements.
+If we further restrict ourselves to the case where $p_{i,i} \lt 1$ (meaning there are no infinite self-loops) then all the diagonal entries are positive and the matrix has an inverse with no negative elements.
 
 Such matrices are known as M-matrices.
 

docs/design/mono/web/aot.md

@@ -105,7 +105,7 @@ It is possible to use LLVM in AOT mode. This is implemented by compiling methods
 
 ### Full AOT mode
 
-Some platforms like the iphone prohibit JITted code, using technical and/or legal means. This is a significant problem for the mono runtime, since it generates a lot of code dynamically, using either the JIT or more low-level code generation macros. To solve this, the AOT compiler is able to function in full-aot or aot-only mode, where it generates and saves all the neccesary code in the aot image, so at runtime, no code needs to be generated. There are two kinds of code which needs to be considered:
+Some platforms like the iphone prohibit JITted code, using technical and/or legal means. This is a significant problem for the mono runtime, since it generates a lot of code dynamically, using either the JIT or more low-level code generation macros. To solve this, the AOT compiler is able to function in full-aot or aot-only mode, where it generates and saves all the necessary code in the aot image, so at runtime, no code needs to be generated. There are two kinds of code which needs to be considered:
 
 -   wrapper methods, that is methods whose IL is generated dynamically by the runtime. They are handled by generating them in the add_wrappers () function, then emitting them as 'extra' methods.
 -   trampolines and other small hand generated pieces of code. They are handled in an ad-hoc way in the emit_trampolines () function.

docs/design/mono/web/exception-handling.md

@@ -114,7 +114,7 @@ Currently, exceptions are raised by calling mono_raise_exception () in the middl
 
 -   To allow mono_raise_exception () to unwind through native code, we need to save the LMF structures which can add a lot of overhead even in the common case when no exception is thrown. So this is not zero-cost exception handling.
 
-An alternative might be to use a JNI style set-pending-exception API. Runtime code could call mono_set_pending_exception (), then return to its caller with an error indication allowing the caller to clean up. When execution returns to managed code, then managed-\>native wrapper could check whenever there is a pending exception and throw it if neccesary. Since we already check for pending thread interruption, this would have no overhead, allowing us to drop the LMF saving/restoring code, or significant parts of it.
+An alternative might be to use a JNI style set-pending-exception API. Runtime code could call mono_set_pending_exception (), then return to its caller with an error indication allowing the caller to clean up. When execution returns to managed code, then managed-\>native wrapper could check whenever there is a pending exception and throw it if necessary. Since we already check for pending thread interruption, this would have no overhead, allowing us to drop the LMF saving/restoring code, or significant parts of it.
 
 ### libunwind
 

docs/design/mono/web/linear-ir.md

@@ -96,7 +96,7 @@ The JIT allocates a large number of vregs. Most of these are created during the
 ### Transitioning between the two states
 
 -   Most vregs start out being local. Others, like the ones representing the arguments and locals of a method, start out being global.
--   Some transformations done by the JIT can break the invariant that an lvreg is local to a basic block. There is a separate pass, mono_handle_global_vregs (), which verifies this invariant and transforms lvregs into global vregs if neccesary. This pass also does the opposite transformation, by transforming global vregs used only in one bblock into an lvreg.
+-   Some transformations done by the JIT can break the invariant that an lvreg is local to a basic block. There is a separate pass, mono_handle_global_vregs (), which verifies this invariant and transforms lvregs into global vregs if necessary. This pass also does the opposite transformation, by transforming global vregs used only in one bblock into an lvreg.
 -   If an address of a vreg needs to be taken, the vreg is transformed into a global vreg.
 
 JIT Passes

docs/design/mono/web/register-allocation.md

@@ -56,7 +56,7 @@ Some variables might already be allocated to hardware registers during the globa
 
 #### Floating point stack
 
-The x86 architecture uses a floating point register stack instead of a set of fp registers. The allocator supports this by a post-processing pass which keeps track of the height of the fp stack, and spills/loads values from the stack as neccesary.
+The x86 architecture uses a floating point register stack instead of a set of fp registers. The allocator supports this by a post-processing pass which keeps track of the height of the fp stack, and spills/loads values from the stack as necessary.
 
 #### Calls