diff --git a/OAT.xml b/OAT.xml
index 667b2348ef1b1b3c160b56a2ade7aff0915b73b1..e6eb98379816802847dd87c613db6a6cd533b198 100644
--- a/OAT.xml
+++ b/OAT.xml
@@ -16,9 +16,9 @@
 <!-- OSS Audit Tool (OAT) configuration guide:
 basedir: Root dirictory. The basedir + project path is the real source file location.
 licensefile:
-1.If the project does not have "LICENSE" in root dir, please define all the license files in this project. OAT will check license files according to this rule.
+1. If the project does not have "LICENSE" in root dir, please define all the license files in this project. OAT will check license files according to this rule.
 
-tasklist(for batch mode only):
+tasklist (for batch mode only):
 1. task: OAT check task. Each task will start a new thread.
 2. task name: Name of the OAT check task.
 3. task policy: Default policy for projects under this task. This field is mandatory and the specified policy must be defined in policylist.
@@ -34,11 +34,11 @@ policyList:
     "compatibility" is used to check license compatibility in the specified path;
     "license" is used to check source license header in the specified path;
     "copyright" is used to check source copyright header in the specified path;
-    "import" is used to check source dependency in the specified path, such as import ... ,include ...
-    "filetype" is used to check file type in the specified path, supported file types: archive, binary
-    "filename" is used to check whether the specified file exists in the specified path(support projectroot in default OAT.xml), supported file names: LICENSE, README, README.OpenSource
+    "import" is used to check source dependency in the specified path, such as import ... , include ...
+    "filetype" is used to check file type in the specified path. Supported file types: archive, binary
+    "filename" is used to check whether the specified file exists in the specified path (support projectroot in default OAT.xml). Supported file names: LICENSE, README, README.OpenSource
 
-4. policyitem name: This field is used to define the license and copyright. Wherein, "*" means to match all, the "!" prefix means a failure to match this value. For example, "!GPL" means a failure to use GPL license.
+4. policyitem name: This field is used to define the license and copyright. Wherein, "*" means to match all, the "!" prefix means a failure to match this value. For example, and "!GPL" means a failure to use GPL license.
 5. policyitem path: This field is used to define the source file scope to apply this policyitem. The "!" prefix means to exclude the files. For example, "!.*/lib/.*" means to exclude the files in lib while processing this policyitem.
 6. policyitem rule and group: These two fields are used together to merge policy results. "may" policyitems in the same group means that the result will be passed if any policyitem in this group is passed,
 7. policyitem filefilter: This field is used to bind file filters, which define filter rules.
@@ -86,7 +86,7 @@ Note: If the text contains special characters, please escape them according to t
                 <filteritem type="filepath" name="scripts/dep-lists/ubuntu-fuzzing" desc="Ubuntu build dependencies"/>
             </filefilter>
             <filefilter name="defaultPolicyFilter" desc="Filter rules of the verification policy for the license file in the root directory" >
-                <filteritem type="filepath" name="AUTHORS" desc="开发者名单"/>
+                <filteritem type="filepath" name="AUTHORS" desc="Authors list"/>
                 <filteritem type="filepath" name="scripts/dep-lists/ubuntu-18-04-arm-dev" desc="Ubuntu build dependencies"/>
                 <filteritem type="filepath" name="scripts/dep-lists/ubuntu-18-04-build" desc="Ubuntu build dependencies"/>
                 <filteritem type="filepath" name="scripts/dep-lists/ubuntu-18-04-ci" desc="Ubuntu build dependencies"/>
@@ -111,5 +111,4 @@ Note: If the text contains special characters, please escape them according to t
             </filefilter>
         </filefilterlist>
     </oatconfig>
-</configuration>
-
+</configuration>
\ No newline at end of file
diff --git a/docs/bc_verification/absint_checks.md b/docs/bc_verification/absint_checks.md
index 3cf24b8e714ad265734265800ca47b04c158034a..b31a5809fb9615629e6d6dfb254812ed77eca48b 100644
--- a/docs/bc_verification/absint_checks.md
+++ b/docs/bc_verification/absint_checks.md
@@ -1,37 +1,37 @@
-## Checks performed on abstract interpretation stage
+## Checks in the Abstract Interpretation Stage
 
-### Physical compatibility of arguments to instructions and actual parameters to methods
+### Physical Compatibility of Arguments to Instructions and Actual Parameters to Methods
 
 This type of checks eliminate runtime problems with undefined bits in integers, truncation issues, etc.
 
-From security point of view, this checks guarantee expected ranges of values in code and absence of handling
+From the security perspective, it can guarantee expected ranges of values in code and absence of handling
 undefined information.
 
-### Access checks
+### Access Checks
 
 This type of checks ensure private/protected/public access rights.
 
-This type of checks prevent unintended/unexpected access from one method to another.
-Or access to wrong fields of object.
+It can prevent unintended/unexpected access from one method to another, 
+or access to wrong fields of object.
 
-### Checks of subtyping
+### Subtyping Checks 
 
 This type of checks ensure compatibility of objects in arguments to instructions and actual parameters to methods.
 
-The checks eliminate calls of methods with incorrect this, wrong access to arrays, etc.
+It can eliminate calls of methods with incorrect parameters, wrong access to arrays, etc.
 
-### Checks of exception handlers
+### Checks of Exception Handlers
 
 This type of checks ensure correctness of context on exception handler entry.
 
-The checks can help to detect usage of inconsistent information in registers in exception handlers.
+It can help to detect usage of inconsistent information in registers in exception handlers.
 
-### Checks of exceptions that may be thrown in runtime
+### Checks of Exceptions That May be Thrown in Runtime
 
 Some code may exhibit behavior of permanent throwing of exceptions, for example, NPE.
 
 This is definitely not normal mode of control-flow in code, so verifier should be able to detect such situations in which an exception is always thrown.
 
-### Check of return values from methods
+### Checks of Return Values from Methods
 
 This type of checks eliminate inconsistency between the method signature and the type of actual return value.
diff --git a/docs/rationale-for-bytecode.md b/docs/rationale-for-bytecode.md
index e06b800429a274fb3b1eb6785c800a7383ef5a72..7bd972fa0505a27d54b2c1356ee12c87712afda1 100644
--- a/docs/rationale-for-bytecode.md
+++ b/docs/rationale-for-bytecode.md
@@ -5,16 +5,16 @@
 This document sets up some context about bytecode design principles and provides rationales for
 bytecode design in Panda Runtime.
 
-## Bytecode basics
+## Bytecode Basics
 
 Before discussing bytecode, let's take a look at a simplified picture of how a program is running on hardware.
 
 There is a central processing unit (CPU) that reads commands (or _instructions_) from
-somewhere in memory and executes corresponding _operations_ on operation's arguments,
+somewhere in the memory and executes corresponding _operations_ on operation's arguments,
 also known as operation's _operands_. Operands may be _registers_ (very fast "variables" located
-directly on the CPU) or _memory_ (some locations in computer's RAM). An important subset of memory
+directly on the CPU) or _memory_ (some locations in the computer's RAM). An important subset of memory
 operands are _stack operands_ that reside in a special data structure called _stack_. The program
-must maintain the stack in the correct state during runtime because exactly this data structure
+must maintain the stack in the correct state during runtime because this data structure
 is used for storing local variables along with function arguments and doing function calls.
 
 In real world, different CPU manufacturers provide different sets of commands for their devices –
@@ -39,7 +39,7 @@ an abstract system from the hardware.
 Just as real CPUs can expose different instruction set architectures, there is no universal way of
 building bytecode. Following sections explain advantages and disadvantages of various approaches.
 
-## Encoding operands
+## Encoding Operands
 
 One important question is how an operation refers to its operands.
 
@@ -65,7 +65,7 @@ In a _register-based approach_, operands are explicitly encoded in the operation
 .end
 ```
 
-This example demonstrates a fundamental difference between two approaches. Stack-based approach
+This example demonstrates the fundamental difference between two approaches. Stack-based approach
 operates with smaller instructions. Indeed, each instruction `push_arg1`, `push_arg1`, and `add`
 can be represented with a single byte, while register-based `add reg_dst, reg_src1, reg_src2` may
 require up to 4 bytes to encode.
@@ -84,13 +84,13 @@ is very important since bytecode interpretation is a required program execution
 
 To address the issue of compactness, two main tweaks are used:
 
-* Implicitly addressed accumulator register.
-* Variable size of instructions in frequently used instructions are encoded to be smaller.
+* Implicitly addressed accumulator register
+* Encoding of instructions of variable sizes in frequently used instructions
 
 According to our research, these tweaks will allow to reduce the size of uncompressed bytecode by
 ~20% compared to Dalvik bytecode.
 
-### Implicitly addressed accumulator register
+### Implicitly Addressed Accumulator Register
 
 Panda bytecode has a dedicated register called _accumulator_, which is addressed implicitly
 by some bytecodes. With this tweak, our example can be rewritten as follows:
@@ -121,7 +121,7 @@ In an ideal case, accumulator register may save us ~25% of size. But it needs to
 To minimize the risk of generating inefficient bytecode with redundant moves from and to
 the accumulator, a simple optimizer will be introduced as a part of the toolchain.
 
-### Variable size of instructions
+### Encoding of Instructions of Variable Sizes
 
 Let's take a closer look at `adda arg1, arg2`. Assume that arguments map to virtual registers on
 the virtual stack as follows:
@@ -171,7 +171,7 @@ be beneficial. For example, we have three types of instructions for integer-size
 overloads are calls (different number of operands) and calls are the most popular instructions in
 applications (thus we again save encoding space).
 
-## Handling various data types
+## Handling Various Data Types
 
 Another important question is how various data types are handled in bytecodes. As for the
 adda ... instruction, what are the types of its operands?
diff --git a/docs/runtime-class.md b/docs/runtime-class.md
index d8c24599836c800b1508203f8fb4d72b5a8aabd8..79bea167542acd7a548d8e80294b73549e21a505 100644
--- a/docs/runtime-class.md
+++ b/docs/runtime-class.md
@@ -1,4 +1,4 @@
-# Runtime class
+# Runtime Class
 
 Panda runtime uses `panda::Class` to store all necessary language independent information about classes. Virtual table and region for static fields are embedded to the `panda::Class` object so it has variable size. To get fast access to them, the `Class Word` field of the object header points to the instance of this class. `ClassLinker::GetClass` also returns an instance of the `panda::Class`.
 
@@ -35,7 +35,7 @@ The layout of the `coretypes::Class` is as follows:
                                                 |      ...         |
                                                 +------------------+
 
-Note: The `panda::Class` object must be the last in the mirror class because it has variable size.
+Note: The `panda::Class` object must be at the last in the mirror class because it has variable size.
 
 Such layout allows to get pointer to the `panda::Class` object from the `coretypes::Class` one and vice versa without dereferencies if we know language context and it's constant (some language specific code):
 
diff --git a/docs/runtime-compiled_code-interaction.md b/docs/runtime-compiled_code-interaction.md
index 1e0e330ef7cbc77fbd2812463140fbfe18fbb117..2ff077beee1f5c2509fb37771243d8e6201e64a7 100644
--- a/docs/runtime-compiled_code-interaction.md
+++ b/docs/runtime-compiled_code-interaction.md
@@ -1,4 +1,4 @@
-# Interaction of compiled code and the runtime
+# Interaction Between the Compiled Code and the Runtime
 
 ## Introduction
 
@@ -11,7 +11,7 @@ Compiled code and Panda runtime interact with each other during execution. This
 * Deoptimization
 * Stack unwinding during exception handling
 
-## Panda runtime (the runtime)
+## Panda Runtime
 Panda runtime is a set of functions used to execute managed code. The runtime consists of several modules.
 The document describes the interpreter and the compiler modules.
 
@@ -22,7 +22,7 @@ The compiler translates bytecodes of managed functions to native code. The compi
 `panda::CompilerInterface::CompileMethodSync` for compilation. When a function is compiled, the compiler changes
 its entrypoint to the native code generated. When the function is called next time, the native code will be executed.
 
-## Calling convention
+## Call Conventions
 Panda runtime and managed code must call functions according to the target calling convention.
 Compiled code of a managed function must accept one extra argument: the pointer to `panda::Method` which describes this function.
 This argument must be the first argument.
@@ -47,24 +47,24 @@ The function must return the result in the register R0.
 | runtime_entrypoints_ | void*[]               | A table of runtime entrypoints (See [Runtime entrypoints](#runtime_entrypoints)). |
 | stack_frame_kind_    | StackFrameKind        | A kind of the current stack frame (compiled code or interpreter stack frame). |
 
-## Access to `panda::ManagedThread` from compiled code
+## Access to `panda::ManagedThread` from the Compiled Code
 There is an allocated register for each target architecture to store a pointer to `panda::ManagedThread`. This register is called `thread register` and
 must contain a valid pointer to `panda::ManagedThread` on entry to each compiled function.
 
-## Runtime entrypoints
+## Runtime Entrypoints
 Runtime serves compiled code via runtime entrypoints. A runtime entrypoint is a function which conforms to the target calling convention.
 A table of the entrypoints is located in `panda::ManagedThread::runtime_entrypoints_` which could be accessed via `thread register`.
 
 ## Structure of `panda::Method`
-`panda::Method` describes a managed function in the runtime.
-This document describes the following fields of `panda::Method`:
+`panda::Method` represents a managed function in the runtime.
+It contains the following key fields:
 
 | Field | Description |
 | ----- | ----------- |
 | hotness_counter_ | A hotness counter of the managed function. |
 | compiled_entry_point_ | Function entrypoint. |
 
-### Hotness counter
+### Hotness Counter
 The field `hotness_counter_` reflects hotness of a managed function. The interpreter increments it each time the function is called,
 backward branch is taken and call instruction is handled.
 When the hotness counter gets saturated (reaches the threshold), the interpreter triggers compilation of the function.
@@ -77,15 +77,15 @@ The managed function may have compiled code or be executed by the interpreter.
 If the function has compiled code the `compiled_entry_point_` must point to compiled code.
 If the function is executed by the interpreter, the `compiled_entry_point_` must point to a runtime function `CompiledCodeToInterpreterBridge` which calls the interpreter.
 
-## Stack frame
+## Stack Frame
 A stack frame contains data necessary to execute the function the frame belongs to.
 The runtime can create several kinds of stack frames. But all the frames of managed code must have the structure described in [Compiled code stack frame](#compiled-code-stack-frame).
 
-### Interpreter stack frame
+### Interpreter Stack Frame
 Interpreter stack frame is described by `panda::Frame` class. The class has fields to store virtual registers and a pointer to the previous stack frame.
 All the consecutive interpreter stack frames are organized into a linked list. The field `panda::Frame::prev_` contains a pointer to the previous interpreter (or compiled bridge) frame.
 
-### Compiled code stack frame
+### Compiled Code Stack Frame
 Each compiled function is responsible for reserving stack frame for its purpose and then release it when the function doesn't need it.
 Generally compiled function builds the stack frame in prolog and releases it in epilog. If a compiled function doesn't require
 the stack frame it can omit its creation.
@@ -141,7 +141,7 @@ There are two special registers: `stack pointer` and `frame pointer`.
 Panda has a special class for getting cframe layout: `class CFrameLayout`. Everything related to the cframe layout
 should be processed via this class.
 
-## Calling a function from compiled code
+## Calling a Function from the Compiled Code
 To call a managed function, the compiled code must resolve it (i.e. retrieve a pointer to callee's `panda::Method`),
 prepare arguments in the registers and the stack (if necessary) and jump to callee's entrypoint.
 Resolving of a function could be done by calling the corresponding runtime entrypoint.
@@ -166,7 +166,7 @@ blx lr // call max('max_method', 2, 3)
 // r0 contains the function result
 ```
 
-## Calling a function from compiled code: Bridge function
+## Calling a Function from the Compiled Code Via the Bridge function
 The compiler has an entrypoints table. Each entrypoint contains a link to the bridge function.
 The bridge function is auto-generated for each runtime function to be called using the macro assembly.
 The bridge function sets up the Boundary Frame and performs the call to the actual runtime function.
@@ -206,7 +206,7 @@ Bridge function stack frame:
         +  16-byte alignment pad to the next frame +
 ```
 
-## Transition from the interpreter to compiled code
+## Transition from the Interpreter to the Compiled Code
 When the interpreter handles a call instruction, it first resolves the callee method.
 The procedure varies depending on the callee's entrypoint:
 If the entrypoint points to `CompiledCodeToInterpreterBridge`, the interpreter executes the callee. In this case the interpreter calls itself directly.
@@ -246,7 +246,7 @@ The structure of boundary frame is the same as a stack frame of compiled code.
 Instead of pointer to `panda::Method` the frame contains constant `INTERPRETER_TO_COMPILED_CODE_BRIDGE`.
 Frame pointer points to the previous interpreter frame.
 
-## Transition from compiled code to the interpreter
+## Transition from the Compiled Code to the Interpreter
 If a function needs be executed by the interpreter, it must have `CompiledCodeToInterpreterBridge` as an entrypoint.
 `CompiledCodeToInterpreterBridge` does the following:
 * Changes stack frame kind in `panda::ManagedThread::stack_frame_kind_` to interpreter stack frame.
@@ -281,7 +281,7 @@ Instead of a pointer to `panda::Method` the frame contains constant `COMPILED_CO
 Frame pointer points to the previous frame in compiled code stack frame.
 The field `panda::Frame::prev_` must point to the boundary frame pointer.
 
-## Stack traversing
+## Stack Traversing
 Stack traversing is performed by the runtime. When the runtime examines a managed thread's stack, the thread cannot execute any managed code.
 Stack unwinding always starts from the top frame, the kind of which can be determined from `panda::ManagedThread::stak_frame_kind_` field. The pointer
 to the top frame can be determined depending on the kind of the top stack frame:
@@ -386,7 +386,7 @@ The function reconstructs the interpreter stack frame and calls the interpreter.
 When compiled code is combined from several managed functions (inlined functions) `Deoptimize` reconstructs interpreter stack frame and calls the interpreter for each inlined function too.
 
 Details in [deoptimization documentation](deoptimization.md)
-## Throwing an exception
+## Throwing an Exception
 Throwing an exception from compiled code is performed by calling the runtime entrypoint `void ThrowException(panda::ObjectHeader* exception)`.
 The function `ThrowException` does the following:
 * Saves all the callee-saved registers to the stack
diff --git a/docs/runtime-debug-api.md b/docs/runtime-debug-api.md
index 83764a271761d876a4e835f7673371ff48142b67..014714079631874bd878cb92f78cb82cef35e961 100644
--- a/docs/runtime-debug-api.md
+++ b/docs/runtime-debug-api.md
@@ -2,23 +2,23 @@
 
 ### Requirements
 
-1. Runtime should support debugging on the platforms from low-end IoT devices to high-end mobile phones.
+Runtime should support debugging on platforms ranging from IoT devices to mobile phones.
 
 ### Key Design Decisions
 
-1. Runtime doesn't patch apps' bytecode on the fly. Instead, it notifies the listeners when the PC of bytecode is changed.
+- Runtime doesn't patch apps' bytecode on the fly. Instead, it notifies the listeners when the PC of bytecode is changed.
 
-1. Runtime and debugger work in the same process. Debugger functionality is provided via shared library, the runtime loads when working in debug mode. Debugger works in its own thread and is responsible for thread management rely on it. Runtime doesn't create/destroy threads.
+- Runtime and debugger work in the same process. Debugger functionality is provided via shared library, the runtime loads when working in debug mode. Debugger works in its own thread and is responsible for thread management rely on it. Runtime doesn't create/destroy threads.
 
 ### Rationale
 
-1. As some low-end targets can store bytecode in ROM, runtime cannot patch apps' bytecode on the fly. So it uses slower approach with interpreter instrumentation.
+- As some low-end targets can store bytecode in ROM, runtime cannot patch apps' bytecode on the fly. So it uses slower approach with interpreter instrumentation.
 
-1. To simplify communication between debugger and runtime (especially on microcontrollers) they are work in the same process. Debugger is loaded as shared library when it's necessary.
+- To simplify communication between debugger and runtime (especially on microcontrollers) they are work in the same process. Debugger is loaded as shared library when it's necessary.
 
 ### Specification / Implementation
 
-To start runtime in debug mode, the `Runtime::StartDebugger()` method is used. This method loads the debug library and calls the `StartDebugger` function from it. It takes pointer to [`debug::Debugger`](../runtime/tooling/debugger.h) object that implements [debug interface](../runtime/include/tooling/debug_interface.h) - point of interaction with the runtime.
+To start runtime in debug mode, use the `Runtime::StartDebugger()` method. This method loads the debug library and calls the `StartDebugger` function from it. It takes pointer to [`debug::Debugger`](../runtime/tooling/debugger.h) object that implements [debug interface](../runtime/include/tooling/debug_interface.h) - point of interaction with the runtime.
 Also it takes a TCP port number and a reserved argument.
 
 Runtime provides [`RuntimeNotificationManager`](../runtime/include/runtime_notification.h) class that allows to subscribe to different events:
@@ -26,4 +26,4 @@ Runtime provides [`RuntimeNotificationManager`](../runtime/include/runtime_notif
 * `StartProcess` - occurs when the managed process is started or failed to start
 * `BytecodePcChanged` - occurs when the PC of bytecode is changed during interpretation (only if runtime works in debug mode)
 
-[`debug::Debugger`](../runtime/tooling/debugger.h) subscribes to these events and notifies debugger via hooks.
+[`debug::Debugger`](../runtime/tooling/debugger.h) subscribes to these events and notifies the debugger via hooks.
diff --git a/docs/tracing.md b/docs/tracing.md
index ad4c0d85caca1749d52fbcb48b147b944ec4959d..4a4193c91b678df584591fd1ab4b5090a4265328 100644
--- a/docs/tracing.md
+++ b/docs/tracing.md
@@ -1,10 +1,10 @@
 # Panda Tracing
 
-This document describes the **Panda trace** subsystem. The subsystem provides an API for creating *tracepoints* to track key points in the runtime. The subsystem uses the `ftrace` ring buffer to record the trace.
+The Panda Tracing subsystem provides an API for creating *tracepoints* to track key points in the runtime. The subsystem uses the `ftrace` ring buffer to record the trace.
 
 ## API
-The Trace API is described in the libpandabase/trace/trace.h file. It supports tracing a scope execution time and tracking a parameter value.
-### Usage examples:
+The Trace API is described in the **libpandabase/trace/trace.h** file. It supports tracing a scope execution time and tracking a parameter value.
+### Usage Example
 ```cpp
 ...
 #include "trace/trace.h"
@@ -37,7 +37,7 @@ void FunctionE(int allocated_bytes) {
 }
 ```
 
-## Recording a trace
+## Recording a Trace
 
 To record and view a trace, perform the following steps:
 
@@ -50,4 +50,4 @@ sudo scripts/trace_enable.sh <output_file> <trace_time_in_seconds>
 PANDA_TRACE=1 panda <args>
 ```
 3. Stop tracing by ^C if the trace time is still running out.
-4. Load <output_file> in Chrome at the `chrome://tracing` address.
+4. Load <output_file> from Chrome at the following address: `chrome://tracing`.