Addressed some more PR comments

doc/compiler/osr/OSR.md

@@ -32,22 +32,22 @@ in the interpreter at the appropriate point.
 
 # High Level Sequence of Events
 
-OSR is typically triggered by some VM event that applies to a compiled method that is currently on stack.
-For example, such event can be setting a breakpoint in a method on stack.
-In addition, if assumptions that the compiler made while compiling a method are invalidated, OSR might eventually be triggered for the method as well.
+OSR is typically triggered by some VM event that applies to a compiled method that is currently on the stack.
+For example, such an event could be an attempt to set a breakpoint in a method on the stack.
+In addition, if assumptions that the compiler made while compiling a method are invalidated, OSR might eventually be triggered for the method as well. In this case, the VM event is an attempt to do something that would violate an assumption (like method redefintion).
 
 
-A VM event can be detected at certain points during execution of a compiled code. These points are called **OSR yield points**. The JIT and the VM agree on the set of the OSR yield points.
+A VM event can be detected at certain points during execution of compiled code. These points are called **OSR yield points**. The JIT and the VM agree on the set of OSR yield points.
 
-Usually, we would like the VM event to be discovered relatively soon after it took place. [Garbage Collection (GC) point](https://github.com/eclipse/omr/blob/81b79405da6c7c960e611a8b2b12fd5861543330/compiler/il/OMRNode.cpp#L2298) meet such criteria.
+Usually, we would like the VM event to be discovered relatively soon after it took place. [Garbage Collection (GC) points](https://github.com/eclipse/omr/blob/81b79405da6c7c960e611a8b2b12fd5861543330/compiler/il/OMRNode.cpp#L2298) meet such criteria.
 Therefore, depending on the event, OSR yield points usually include all or a subset of GC points.
-The reason why we would like to limit the set of the OSR yield points, if possible, is the cost of the bookkeeping associated with each such point as well as the restrictions that they impose on the optimizer.
+The reason why we would like to limit the set of OSR yield points, if possible, is the cost of the bookkeeping associated with each such point as well as the restrictions that they impose on the optimizer.
 
-The actual OSR happens at **OSR Induction points**. They can happen at the time of the yield or later, as described in the following sections.
+The actual OSR transition happens at **OSR Induction points**. It can happen at the time of the yield or later, as described in the following sections.
 
-Note that sometimes the VM event does not finish until OSR transition is done. Therefore, in the most general case, a high level sequence of events can be described as following:
+Therefore, at a high level, the sequence of events can be described as follows:
 
-    VM event initiation => OSR yield => OSR induction => OSR transition => VM event completion
+       VM event => OSR yield => OSR induction => OSR transition
 
 
 # Voluntary and Involuntary OSR
@@ -61,12 +61,12 @@ OMR provides infrastructure for involuntary OSR. Downstream projects can impleme
 
 # Inducible and Uniducible OSR Yield Points
 
-During voluntary OSR, the JIT can induce OSR after practically every OSR yield point and those points are called **inducible OSR yield points**. However, there are some OSR yield points after which the JIT cannot induce OSR. Those are referred to as **uninducible OSR yield points**. A typical example of uninducible OSR yield point is when there is a thunk archetype present on the inline stack.
+During voluntary OSR, the JIT can induce OSR after practically every OSR yield point and those points are called **inducible OSR yield points**. However, there are some OSR yield points after which the JIT cannot induce OSR. Those are referred to as **uninducible OSR yield points**. A typical example of an uninducible OSR yield point is when there is a thunk archetype present on the inline stack.
 
 
 # Pre- and Post-Execution OSR
 
-In the Pre-execution OSR mode, OSR happens before the side-effects of executing the OSR yield take place. For example, if a monitor enter was identified as an OSR yield point, the VM induses OSR before entering the monitor. Then, we reconstruct the state such that the VM's interpreter can begin execution of the monitor enter.
+In the Pre-execution OSR mode, OSR happens before the side-effects of executing the OSR yield take place. For example, if a monitor enter was identified as an OSR yield point, the VM induces OSR before entering the monitor. Then, we reconstruct the state such that the VM's interpreter can begin execution of the monitor enter.
 
 Under post-execution OSR, the transition occurs after the OSR yield point has been evaluated in the compiled code.
 
@@ -232,7 +232,7 @@ At the end of each OSR code block, we either return control back to the VM by ca
 
 Generally, execution is transitioned from optimized code to interpreted code once we are in OSR mode.
 However, there is an exception to this rule. If both the VM and the JIT agree that we can resume executing optimized code after reconstructing interpreter stack frames,
-we will not transition to interpreter. A possible debugging scenario when this can happen is when a user pauses application execution, inspects all stack variables,
+we will not transition to the interpreter. A possible debugging scenario when this can happen is when a user pauses application execution, inspects all stack variables,
 and then continues execution without any other debugging actions.
 
 **TODO:** document this scenario in more detail