[docs] Fix typos in recently added BotR chapters

diff --git a/Documentation/clr-code-guide.md b/Documentation/clr-code-guide.md
index 8d6567f..96f60f1 100644 (file)
--- a/Documentation/clr-code-guide.md
+++ b/Documentation/clr-code-guide.md
@@ -217,7 +217,7 @@ How about the alternative: cooperative GC? With cooperative GC, the above proble
 
 Because neither policy alone suffices for the CLR, the CLR supports both: and you, as a developer, are responsible for switching the threads accordingly. Note that the GC-scheduling mode is a property of an individual thread; not a global system property.
 
-Put precisely: as long as a thread is in cooperative mode, it is guaranteed that a GC will only occur when your thread triggers an object allocation, calls out to interruptable managed code or explicitly requests a GC. All other threads are blocked from GC. As long as your thread is in preemptive mode, then you must assume that a GC can be started any time (by some other thread) and is running concurrently with your thread.
+Put precisely: as long as a thread is in cooperative mode, it is guaranteed that a GC will only occur when your thread triggers an object allocation, calls out to interruptible managed code or explicitly requests a GC. All other threads are blocked from GC. As long as your thread is in preemptive mode, then you must assume that a GC can be started any time (by some other thread) and is running concurrently with your thread.
 
 A good rule of thumb is this: a CLR thread runs in cooperative mode any time it is running managed code or any time it needs to manipulate object references in any way. An Execution Engine (EE) thread that is running in preemptive mode is usually running unmanaged code; i.e. it has left the managed world. Process threads that have never entered CLR in any way are effectively running in preemptive mode. Much of the code inside CLR runs in cooperative mode.
 
@@ -242,7 +242,7 @@ There are a couple of variants for special situations:
 - **GCX_MAYBE_\*(BOOL)**: This version only performs the switch if the boolean parameter is TRUE. Note that the mode restore at the end of the scope still occurs whether or not you passed TRUE. (Of course, this is only important if the mode got switched some other way inside the scope. Usually, this shouldn't happen.)
 - **GCX_\*_THREAD_EXISTS(Thread\*)**: If you're concerned about the repeated GetThread() and null Thread checks inside this holder, use this "performance" version which lets you cache the Thread pointer and pass it to all the GCX_\* calls. You cannot use this to change the mode of another thread. You also cannot pass NULL here.
 
-To switch modes multiple times in a function, you must introduce a new scope for each switch. You can also call GCX_POP(), which performs a mode restore prior to the end of the scope. (The mode restore will happen again at the end of the scope, however. Since mode restore is idempodent, this shouldn't matter.) Do not, however, do this:
+To switch modes multiple times in a function, you must introduce a new scope for each switch. You can also call GCX_POP(), which performs a mode restore prior to the end of the scope. (The mode restore will happen again at the end of the scope, however. Since mode restore is idempotent, this shouldn't matter.) Do not, however, do this:
 
        {
             GCX_COOP();
@@ -259,7 +259,7 @@ While the holder-based macros are the preferred way to switch modes, sometimes o
 
 There is no automatic mode-restore with these functions so the onus is on you to manage the lifetime of the mode. Also, mode changes cannot be nested. You will get an assert if you try to change to a mode you're already in. The "this" argument must be the currently executing thread. You cannot use this to change the mode of another thread.
 
-**Key Takeway:** Use GCX_COOP/PREEMP rather than unscoped calls to DisablePreemptiveGC() whenever possible.
+**Key Takeaway:** Use GCX_COOP/PREEMP rather than unscoped calls to DisablePreemptiveGC() whenever possible.
 
 **Testing/asserting the GC mode:**
 
@@ -556,7 +556,7 @@ This means that:
 
 - Any operation that fails due to an OOM must allow future retries. This means any changes to global data structures must be rolled back and OOM exceptions cannot be cached. 
 - OOM failures must be distinguishable from other error results. OOM's must never be transformed into some other error code. Doing so may cause some operations to cache the error and return the same error on each retry. 
-- Every function must declare whether or not it can generate an OOM error. We cannot write OOM-safe code if we have no way to know what calls can generate OOM's. This declation is done by the INJECT_FAULT and FORBID_FAULT contract annotations. 
+- Every function must declare whether or not it can generate an OOM error. We cannot write OOM-safe code if we have no way to know what calls can generate OOM's. This declaration is done by the INJECT_FAULT and FORBID_FAULT contract annotations. 
 
 ### Documenting where OOM's can happen.
 

diff --git a/Documentation/dotnet-filenames.md b/Documentation/dotnet-filenames.md
index 4fa2a73..e12f05b 100644 (file)
--- a/Documentation/dotnet-filenames.md
+++ b/Documentation/dotnet-filenames.md
@@ -5,7 +5,7 @@
 
 - coreclr.dll: The implementation of CoreCLR.
 - clr.dll: The implemenation of the .NET Framework CLR since the .NET Framework 4.
-- mscorwks.dll: The .NET Framework CLR implementation up until version 2/3.5. It was called "wks" (pronounced "works") because it originally contained the client or "workstation" GC. Up until the .NET Framework 2, there was another variant of the CLR that contained the "server" GC, called msworksvr.dll. In the .NET Framework 2 release, the workstation and server GC were merged together in a single implementation, in mscorwks.dll, while mscorsvr.dll was deprecated.
+- mscorwks.dll: The .NET Framework CLR implementation up until version 2/3.5. It was called "wks" (pronounced "works") because it originally contained the client or "workstation" GC. Up until the .NET Framework 2, there was another variant of the CLR that contained the "server" GC, called mscorsvr.dll. In the .NET Framework 2 release, the workstation and server GC were merged together in a single implementation, in mscorwks.dll, while mscorsvr.dll was deprecated.
 - mscorsvr.dll: See mscorwks.dll.
-- mscordacwks: A variant of mscorwks.dll (for the .NET Framework CLR), used only/primarily while debugger. It contains the "DAC" version of the VM implementation.
-- mscordaccore.dll: A variant of coreclr.dll (for .NET Core), used only/primarily while debugger. It contains the "DAC" version of the VM implementation.
\ No newline at end of file
+- mscordacwks: A variant of mscorwks.dll (for the .NET Framework CLR), used only/primarily while debugging. It contains the "DAC" version of the VM implementation.
+- mscordaccore.dll: A variant of coreclr.dll (for .NET Core), used only/primarily while debugging. It contains the "DAC" version of the VM implementation.

diff --git a/Documentation/stackwalking.md b/Documentation/stackwalking.md
index 5c97b64..351fefa 100644 (file)
--- a/Documentation/stackwalking.md
+++ b/Documentation/stackwalking.md
@@ -2,7 +2,7 @@ Stackwalking in the CLR
 ---
 Author: Rudi Martin ([@Rudi-Martin](https://github.com/Rudi-Martin)) - 2008
 
-The CLR makes heavy use of a technique known as stack walking (or stack crawling). This involves iterating the sequence of calls frames for a particular thread, from the most recent (the thread's current function) back down to the base of the stack.
+The CLR makes heavy use of a technique known as stack walking (or stack crawling). This involves iterating the sequence of call frames for a particular thread, from the most recent (the thread's current function) back down to the base of the stack.
 
 The runtime uses stack walks for a number of purposes:
 
@@ -19,9 +19,9 @@ Logically, a stack is divided up into some number of _frames_. Each frame repres
 
 The exact definition of a frame varies from platform to platform and on many platforms there isn't a hard definition of a frame format that all functions adhere to (x86 is an example of this). Instead the compiler is often free to optimize the exact format of frames. On such systems it is not possible to guarantee that a stackwalk will return 100% correct or complete results (for debugging purposes, debug symbols such as pdbs are used to fill in the gaps so that debuggers can generate more accurate stack traces).
 
-This is not a problem for the CLR, however, since we do not require a fully generalized stack walk. Instead we are only interested in those frames that are managed (i.e. represent a managed method) or, to some extent, frames coming from unmanaged code used to implement part of the runtime itself. In particular there is no guaruntee about fidelity of 3rd party unmanaged frames other than to note where such frames transition into or out of the runtime itself (i.e. one of the frame types we do care about).
+This is not a problem for the CLR, however, since we do not require a fully generalized stack walk. Instead we are only interested in those frames that are managed (i.e. represent a managed method) or, to some extent, frames coming from unmanaged code used to implement part of the runtime itself. In particular there is no guarantee about fidelity of 3rd party unmanaged frames other than to note where such frames transition into or out of the runtime itself (i.e. one of the frame types we do care about).
 
-Because we control the format of the frames we're interested in (we'll delve into the details of this later) we can ensure that those frames are crawable with 100% fidelity. The only additional requirement is a mechanism to link disjoint groups of runtime frames together such that we can skip over any intervening unmanaged (and otherwise uncrawlable) frames.
+Because we control the format of the frames we're interested in (we'll delve into the details of this later) we can ensure that those frames are crawlable with 100% fidelity. The only additional requirement is a mechanism to link disjoint groups of runtime frames together such that we can skip over any intervening unmanaged (and otherwise uncrawlable) frames.
 
 The following diagram illustrates a stack containing all the frames types (note that this document uses a convention where stacks grow towards the top of the page):
 
@@ -75,7 +75,7 @@ The caller of this method provides three main inputs:
 
 StackWalkFramesEx() returns an enum value that indicates whether the walk terminated normally (got to the stack base and ran out of methods to report), was aborted by one of the callbacks (the callbacks return an enum of the same type to the stack walk to control this) or suffered some other miscellaneous error.
 
-Aside from the context value passed to StackWalkFramesEx(), stack callback functions are passed one other piece of context: the CrawlFrame. This class is defined in [stackwalk.h](https://github.com/dotnet/coreclr/blob/master/src/vm/stackwalk.h) and contains all sorts of context gathered as the stack walk procedes.
+Aside from the context value passed to StackWalkFramesEx(), stack callback functions are passed one other piece of context: the CrawlFrame. This class is defined in [stackwalk.h](https://github.com/dotnet/coreclr/blob/master/src/vm/stackwalk.h) and contains all sorts of context gathered as the stack walk proceeds.
 
 For instance the CrawlFrame indicates the MethodDesc* for managed frames and the Frame* for unmanaged Frames. It also provides the current register set inferred by virtually unwinding frames up to that point.