docs: fix grammar and spelling

doc/guides/gc-arena-howto.md

@@ -14,7 +14,7 @@ GC (garbage collector) must ensure that object is "alive", in other
 words, that it is referenced by somewhere from the program.  This can be
 determined by checking if the object can be directly or indirectly
 referenced by root.  The local variables, global variables and
-constants etc are root.
+constants etc. are root.
 
 If program execution is performed inside mruby VM, there is nothing to
 worry about because GC can access all roots owned by the VM.
@@ -29,7 +29,7 @@ This can be a fatal bug if the GC tries to collect a live object.
 In CRuby, we scan C stack area, and use C variable as root to check
 whether object is alive or not.  Of course, because we are accessing C
 stack just as memory region, we never know it is an integer or a
-pointer.  We workaround this by assuming that if it looks like a
+pointer.  We work around this by assuming that if it looks like a
 pointer, then assume it as a pointer.  We call it "conservative".
 
 By the way, CRuby's "conservative GC" has some problems.
@@ -65,14 +65,14 @@ objects (See `MRB_GC_FIXED_ARENA` and `MRB_GC_ARENA_SIZE` in
 doc/guides/mrbconf.md).
 
 If you create many objects in C functions, memory usage will increase, since
-GC never kick in.  This memory usage may look like memory leak, but will also
+GC never kicks in.  This memory usage may look like memory leaks, but will also
 make execution slower as more memory will need to be allocated.
 
 With the build time configuration, you can limit the maximum size of
 arena (e.g., 100).  Then if you create many objects, arena overflows,
 thus you will get an "arena overflow error".
 
-To workaround these problems, we have `mrb_gc_arena_save()` and
+To work around these problems, we have `mrb_gc_arena_save()` and
 `mrb_gc_arena_restore()` functions.
 
 `int mrb_gc_arena_save(mrb)` returns the current position of the stack

doc/guides/mrbgems.md

@@ -111,7 +111,7 @@ conf.gembox 'custom'
 This will cause the `custom` GemBox to be read in during the build process,
 adding `mruby-time` and `mrbgems-example` to the build.
 
-If you want, you can put GemBox outside of mruby directory. In that case you must
+If you want, you can put GemBox outside the mruby directory. In that case you must
 specify an absolute path like below.
 
 ```ruby

doc/mruby3.0.md

@@ -75,7 +75,7 @@ to be default `mrb_value` representation. Now the default is
 ## `MRB_WORD_BOXING`
 
 Pack `mrb_value` in an `intptr_t` integer. Consumes less
-memory compared to `MRB_NO_BOXING` especially on 32 bit
+memory compared to `MRB_NO_BOXING` especially on 32-bit
 platforms. `Fixnum` size is 31 bits so some integer values
 does not fit in `Fixnum` integers.
 
@@ -116,7 +116,7 @@ Instructions that access pool[i]/syms[i] where i>255.
 * `OP_STRING16`
 * `OP_LOADSYM16`
 
-Instructions that load a 32 bit integer.
+Instructions that load a 32-bit integer.
 
 * `OP_LOADI32`
 

doc/mruby3.1.md

@@ -119,7 +119,7 @@ If the size of `mrb_float` and `mrb_int` are same, the last 2 bits in the `mrb_f
 
 Previous NaN boxing packs values in NaN representation, but pointer retrievals are far more frequent than floating point number references. So we add constant offset to NaN representation to clear higher bits of pointer representation. This representation is called "Favor Pointer" NaN Boxing.
 
-Also, previous NaN boxing limit the size of `mrb_int` to 4 bytes (32 bits) to fit in NaN values. Now we allocates integer values in the heap, if the value does not fit in the 32 bit range, just like we did in Word Boxing.
+Also, previous NaN boxing limit the size of `mrb_int` to 4 bytes (32 bits) to fit in NaN values. Now we allocate integer values in the heap, if the value does not fit in the 32 bit range, just like we did in Word Boxing.
 
 ## Constant Folding