diff --git a/chap1-0829/P1.jpg b/chap1-0829/P1.jpg
new file mode 100644
index 0000000..3f12451
Binary files /dev/null and b/chap1-0829/P1.jpg differ
diff --git a/chap1-0829/P2.png b/chap1-0829/P2.png
new file mode 100644
index 0000000..e7ea232
Binary files /dev/null and b/chap1-0829/P2.png differ
diff --git a/chap1-0829/README.md b/chap1-0829/README.md
new file mode 100644
index 0000000..d4e6690
--- /dev/null
+++ b/chap1-0829/README.md
@@ -0,0 +1,134 @@
+# 连载《Chrome V8 原理讲解》第一篇：V8环境搭建  
+![avatar](../v8.png)  
+# 为什么写这个主题
+Chrome的重要地位不用赘述，V8不仅是chrome的核心组件，还是node.js等众多软件的核心组件，V8的重要程度亦不用多言。V8涉及的技术十分广泛，包括了操作系统、编译技术、计算机系统结构等多方面的知识，而网上的材料或零散或陈旧，给初学者造成了很大的困难，所以我准备写一系列文章，从基础入手，到V8内存分配、Isolate创建、handles概念、builtin、codegen、编译等每个方面进行详细讲解，力求做到概念层面的讲解、有理论依据，又要有代码层面的说明、有事实论证。
+# 本节内容介绍
+本文是这个系列的第一篇，主要讲解四部分内容：一、编译工具链、V8编译和调试；二、如何学习V8代码最容易；三、以JavaScript元素(Element)为例，开启V8源码的学习之旅，起到抛砖引玉的作用；四、元素原理讲解。
+**本文所讲的操作过程要求你的网络能访问谷歌，还要求你的cmd命令行也能通过http(s)访问谷歌。**
+
+# 一、下载、编译、调试
+## 1.系统环境要求
+操作系统 win 10 64bit,VS2019社区版，git  
+操作系统 Win 10 64bit，VS2019社区版，Git，windows 10 SDK至少是10.0.19041以上版，安装SDK时不推荐用VS installer安装，单独下载SDK安装包。原因是installer安装的SDK文件不全。
+## 2.depot_tools工具
+它是v8的编译工具链，下载代码，编译代码都需要用到它。
+* 下载地址：https://storage.googleapis.com/chrome-infra/depot_tools.zip
+* 压缩depot_tools.zip,用鼠标右键压缩，注意：不要双击打开并从中拖拽出来
+* 把depot_tools加入到环境变量PATH中；添加系统变量DEPOT_TOOLS_WIN_TOOLCHAIN=0
+* 打开CMD终端(不是powershell，并且能http(s)访问谷歌),执行gclient。它做一些初始化工作，与v8代码无关，不作深入讲解，可自行查阅源码
+* gclient执行完毕，用where python查看depot_tools中的python.bat的位置，确保python.bat在环境变量PATH中的位置在系统中原有(如果有)的python环境位置前面
+## 3.下载代码
+* git的初始化
+  ```
+  > git config --global user.name "Name"
+  > git config --global user.email "address@mail.com"
+  > git config --global core.autocrlf false
+  > git config --global core.filemode false
+  > git config --global branch.autosetuprebase always
+  ```
+* 下载V8代码  
+  ```
+  fetch v8
+  git pull origin master
+  ```
+  源码不太大，用debug模式编译后需要7G的硬盘空间，建议用固态硬盘，因为文件数量多，VS2019在扫描文件之间的引用关系时，固态很有优势。
+* 生成GN工程文件
+  ```
+  > cd ~\v8\src #进入v8 src目录
+  > gn gen --ide=vs out\default --args="is_component_build = true is_debug = true v8_optimized_debug = false"
+  ```
+  gn命令不是本文重点，可自行查阅。参数：is_debug = true 让v8可以被调试，v8_optimized_debug = false 去掉对调试v8有干扰的代码优化，这不会影响v8的正确性，只可能对性能有点影响,下文是我的编译配置文件args.gn。
+  ```
+  is_component_build = true  
+  is_debug = true  
+  v8_optimized_debug = false  
+  v8_use_snapshot = false
+  ```  
+## 4.编译、调试
+用VS2019编译V8  
+在src\out\default下，能看到all.sln，双击打开,如图-1。  
+![avatar](vs0.png)    
+在解决方案资源管理器中，能看到v8_hello_world这个方案，鼠标右击“设为启动项目”，再次鼠标右击“生成”，这样就开始编译了，在图1下方的输出窗口，能看到编译过程。编译时间长短要看机器性能：CPU和内存频率、硬盘读写速度。 
+![avatar](stack.png)   
+上图是跟踪hello world的调用堆栈。   
+总结，环境搭建过程中可能会出现意想不到的问题，多半都和SDK版本、环境变量有关，详细查看出错信息往往会得到答案。  
+
+# 二、更容易入手的学习方法  
+学代码，肯定是可以调试，跟踪最容易，V8代码太大，要有一个合理的入口才好，v8的源码都在src目录下，如下图。
+![avatar](v8tree.jpg)
+还有一个samples目录，这里就是我们开始学习的地方，图1中打开的文件正是hello-world.cc,这是一个hello world程序。V8是一个javascript虚拟机，这个hello word正是在这个V8运行的一个程序，包括了V8的创建、Isolate创建、handle创建，编译，输出hello world，再结束V8的全过程。学习V8的方式就是从跟踪hello-world.cc做起。    
+# 三 、元素(Element)初始化
+  V8在启动全过程涉及很知识，本篇文章的作用为学习V8代码起个头，所以咱们聊聊相对简单的元素(Element)初始化。通过元素的初始化，学习如何跟踪V8代码，以及了角V8的代码风格。  
+  先来说什么是元素，Element是什么？先来看一个概念，{a:"foo",b:"bar"}，这个对象有两个名字属性(name properties)，"a"和"b",它们不能用数组下标索引，有下标索引属性的，通常被称为元素(Element),例如：["foo","bar"],0位置是"foo"，1位置是"bar"。这在V8中的处理方式有很大的不同，先通过一张图说明一下javascipt对象在V8中的表现形式。  
+![avatar](P1.jpg)   
+  从图可以看出，在V8中javaScript对象内部是分开做存储的，name property和元素分开存储的。本节主要讲解element，也就是图版中红色标记的部分。
+  我直接给出跟踪方法，见下图。  
+![avatar](P2.png)  
+  注意图中文件的位置，和断点，调试时就可以在这个位置停下来,这就是跟踪方法，单步进入分析即可。  
+# 四、元素(ELement)原理及重要数据结构  
+## 1.主要代码和数据结构   
+  Element中的大量方法，例如pop或者slice方法等，大多都是用来对一段连续的地址空间进行操作的。ElementsAccessor是操作Element的基类，在Element上的每个操作都会对应到ElmentsAccessor。
+```
+void ElementsAccessor::InitializeOncePerProcess() {
+  static ElementsAccessor* accessor_array[] = {
+#define ACCESSOR_ARRAY(Class, Kind, Store) new Class(),
+     ELEMENTS_LIST(ACCESSOR_ARRAY)//这里初化的宏义
+#undef ACCESSOR_ARRAY
+  };
+
+  STATIC_ASSERT((sizeof(accessor_array) / sizeof(*accessor_array)) ==
+                kElementsKindCount);
+
+  elements_accessors_ = accessor_array;
+}
+```
+  代码中的ACCESSOR_ARRAY和ELEMENTS_LIST两个宏配合完成初始化，ELEMENTS_LIST中也能看到所有种类的Element，也就是Element kinds，如下图所示。  
+![avatar](VS1.png)  
+  以FastPackedSmiElemntsAccessor为例进行分析，这个类从名字可以出来它是连续存储的Smi类型，连续存储是指数据中没有空洞，例如：a =[1,2,3],这就是packed Smi，b = [1,,3],这就是Holey Smi。何为Smi?就是小整数，以32位CPU为例说明，最低的一位(bit)是表示类型的，如果是1，则是指针，是0表示是Smi。  
+  FastPackedSmiElementsAccessor中没有具体实现的功能， 我们直接看他的父类 FastSmiOrObjectElementsAccessor,这里有一些功能的实现，但目前看完这些功能，是没有办法在脑海中构建出一个Element结构来的，现在看还为时尚早，因为这里只有Element的初始化，没有讲它是如何使用的，比如：slice方法是如何实现的，这里并没有详细说明。这里主要说明了初始化，接着看FastElementsAccessor这个父类，这里定义了的功能实现比FastSmiOrObjectElementsAccessor中多，方法名中包含"Normailize"字样的方法非常重要，因为任何一个JavaScript中关于Element的操作方法(比如slice)的执行过程都与Normalize有关，Normalize是Element的操作方法到最终实现之间的必经之路。  
+![avatar](VS2.png)  
+  NormalizeImpl是Normalize方法的具体实现。再进入下一个父类  
+![avatar](VS3.png)  
+  最后给出类型的嵌套关系，如下图  
+![avatar](VS4.png)  
+  看完这类中的各种方法，感觉方法之间无法关联起，这是正常的，因为目前为止，我们还没有进入方法的调用过程。  
+## 2.从element.length看执行过程  
+  到目前为止，我们还只是看ELement的初始化过程，如果能让所有的成员动起来，可以提高我们的学习效率。借助debug来做个测试，如下图  
+![avatar](VS5.png)  
+  我们调试的是shell.cc，它的位置在samples\下。调试之前要把这个工程编译，看图中右侧的红色标记，可以把这个工程设置为启动项，然后生成，启动debug后看到这到下图。  
+![avatar](VS6.png)
+  这时，我们在elements.cc中下断点，如下图。  
+![avatar](VS7.png)  
+  在这样图中，能看到断点，还有调用堆栈，从中能看到函数的调用过程，在shell窗口中执行如下指令  
+```
+a=[1,2,3,4]
+a.length = 7 //这是特意改变数组长度，为了能触发断点
+```  
+这时就能复原上图的堆栈了，你可以查看附近的相关代码。  
+## 3.数据结构Accessors  
+  我们先来看一下这个结构的部分源代码。  
+```
+// Accessors contains all predefined proxy accessors.
+class Accessors : public AllStatic {
+ public:
+#define ACCESSOR_GETTER_DECLARATION(_, accessor_name, AccessorName, ...) \
+  static void AccessorName##Getter(                                      \
+      v8::Local<v8::Name> name,                                          \
+      const v8::PropertyCallbackInfo<v8::Value>& info);
+  ACCESSOR_INFO_LIST_GENERATOR(ACCESSOR_GETTER_DECLARATION, /* not used */)
+#undef ACCESSOR_GETTER_DECLARATION
+
+#define ACCESSOR_SETTER_DECLARATION(accessor_name)          \
+  static void accessor_name(                                \
+      v8::Local<v8::Name> name, v8::Local<v8::Value> value, \
+      const v8::PropertyCallbackInfo<v8::Boolean>& info);
+  ACCESSOR_SETTER_LIST(ACCESSOR_SETTER_DECLARATION)
+#undef ACCESSOR_SETTER_DECLARATION
+...
+省略很多代码... ....
+...
+```  
+&emsp;&emsp;这个Accessors的作用是什么？通过上面的例子来说明：上面定义的a.length=5的执行过程是：需要先找到它的Accessors，然后再才能到具体的setlength，这正好和V8的ElementsAccessor说明是对应的，如下图。  
+![avatar](VS8.png)  
+好了，今天就到这里，下次见。  
+**微信：qq9123013   邮箱：v8blink@outlook.com 欢迎批评指正**
\ No newline at end of file
diff --git a/chap1-0829/VS1.png b/chap1-0829/VS1.png
new file mode 100644
index 0000000..a81995d
Binary files /dev/null and b/chap1-0829/VS1.png differ
diff --git a/chap1-0829/VS2.png b/chap1-0829/VS2.png
new file mode 100644
index 0000000..69c6609
Binary files /dev/null and b/chap1-0829/VS2.png differ
diff --git a/chap1-0829/VS3.png b/chap1-0829/VS3.png
new file mode 100644
index 0000000..6f6985f
Binary files /dev/null and b/chap1-0829/VS3.png differ
diff --git a/chap1-0829/VS4.png b/chap1-0829/VS4.png
new file mode 100644
index 0000000..d01e692
Binary files /dev/null and b/chap1-0829/VS4.png differ
diff --git a/chap1-0829/VS5.png b/chap1-0829/VS5.png
new file mode 100644
index 0000000..6418619
Binary files /dev/null and b/chap1-0829/VS5.png differ
diff --git a/chap1-0829/VS6.png b/chap1-0829/VS6.png
new file mode 100644
index 0000000..6a704e3
Binary files /dev/null and b/chap1-0829/VS6.png differ
diff --git a/chap1-0829/VS7.png b/chap1-0829/VS7.png
new file mode 100644
index 0000000..121a2bc
Binary files /dev/null and b/chap1-0829/VS7.png differ
diff --git a/chap1-0829/VS8.png b/chap1-0829/VS8.png
new file mode 100644
index 0000000..0af7e51
Binary files /dev/null and b/chap1-0829/VS8.png differ
diff --git a/chap1-0829/stack.png b/chap1-0829/stack.png
new file mode 100644
index 0000000..a5334ae
Binary files /dev/null and b/chap1-0829/stack.png differ
diff --git a/chap1-0829/v8tree.jpg b/chap1-0829/v8tree.jpg
new file mode 100644
index 0000000..983aa16
Binary files /dev/null and b/chap1-0829/v8tree.jpg differ
diff --git a/chap1-0829/v8tree.png b/chap1-0829/v8tree.png
new file mode 100644
index 0000000..12ba013
Binary files /dev/null and b/chap1-0829/v8tree.png differ
diff --git a/chap1-0829/vs0.png b/chap1-0829/vs0.png
new file mode 100644
index 0000000..586f2d4
Binary files /dev/null and b/chap1-0829/vs0.png differ
diff --git a/chap10-1003/README.md b/chap10-1003/README.md
new file mode 100644
index 0000000..c037d67
--- /dev/null
+++ b/chap10-1003/README.md
@@ -0,0 +1,314 @@
+# 连载《Chrome V8 原理讲解》第十篇 V8 Execution源码分析
+![avatar](../v8.png)
+# 1 摘要  
+`Execution`是V8执行Javascript字节码的运行单元，它负责启动Ignition执行字节码。前几篇文章对Javascript的执行过程和理论知识做过介绍。本文重在实践，注重梳理`Execution`工作流程，从`SharedFunction`谈起，跟着Javascript测试用例的执行过程走，代码执行到哪，就讲到哪，详细阐述运行单元`Execution`的具体工作内容、动作步骤和关键节点，给读者展现一个“活动”的V8。  
+
+本文剩余内容按字节码的执行顺序讲解该过程中涉及到的V8源码，故只设置一个章节(章节2)。  
+
+**关键字：** Execution，SharedFunction，Context，BindToCurrentContext 
+# 2 Execution执行单元  
+经过`GetSharedFunctionInfoForScript()`之后，得到了`MayHandle<SharedFunctionInfo>`类型的`maybe_result`数据，见下段代码：
+```c++
+0.  MaybeHandle<SharedFunctionInfo> Compiler::GetSharedFunctionInfoForScript(
+1.      Isolate* isolate, Handle<String> source,
+2.      const Compiler::ScriptDetails& script_details,
+3.      ScriptOriginOptions origin_options, v8::Extension* extension,
+4.      ScriptData* cached_data, ScriptCompiler::CompileOptions compile_options,
+5.      ScriptCompiler::NoCacheReason no_cache_reason, NativesFlag natives) {
+6.  //...................删除部分代码，留下最核心功能
+7.    // Do a lookup in the compilation cache but not for extensions.
+8.    MaybeHandle<SharedFunctionInfo> maybe_result;
+9.    IsCompiledScope is_compiled_scope;
+10.    if (extension == nullptr) {
+11.      bool can_consume_code_cache =
+12.          compile_options == ScriptCompiler::kConsumeCodeCache;
+13.      if (can_consume_code_cache) {
+14.        compile_timer.set_consuming_code_cache();
+15.      }
+16.      // First check per-isolate compilation cache.
+17.      maybe_result = compilation_cache->LookupScript(
+18.          source, script_details.name_obj, script_details.line_offset,
+19.          script_details.column_offset, origin_options, isolate->native_context(),
+20.          language_mode);
+21.      if (!maybe_result.is_null()) {
+22.        compile_timer.set_hit_isolate_cache();
+23.      } 
+24.    }
+25.  //...................删除部分代码，留下最核心功能
+26.    if (maybe_result.is_null()) {
+27.      ParseInfo parse_info(isolate);
+28.      // No cache entry found compile the script.
+29.      NewScript(isolate, &parse_info, source, script_details, origin_options,
+30.                natives);
+31.      // Compile the function and add it to the isolate cache.
+32.      if (origin_options.IsModule()) parse_info.set_module();
+33.      parse_info.set_extension(extension);
+34.      parse_info.set_eager(compile_options == ScriptCompiler::kEagerCompile);
+35.      parse_info.set_language_mode(
+36.          stricter_language_mode(parse_info.language_mode(), language_mode));
+37.      maybe_result = CompileToplevel(&parse_info, isolate, &is_compiled_scope);
+38.      Handle<SharedFunctionInfo> result;
+39.      if (extension == nullptr && maybe_result.ToHandle(&result)) {
+40.        DCHECK(is_compiled_scope.is_compiled());
+41.        compilation_cache->PutScript(source, isolate->native_context(),
+42.                                     language_mode, result);
+43.      } else if (maybe_result.is_null() && natives != EXTENSION_CODE) {
+44.        isolate->ReportPendingMessages();
+45.      }
+46.    }
+47.    return maybe_result;
+48.  }
+```  
+获取`SharedFunction`时先查找`compilation cache`，命中则直接返回结果，样例JS源码是第一次运行，第26行的`maybe_result`是`null`，执行37行的`CompileToplevel()`，得到编译后的结果`maybe_result`。进入Execution执行单元之前，还需要绑定当面上下文，代码如下：
+```c++
+0.  Local<Script> UnboundScript::BindToCurrentContext() {
+1.    auto function_info =
+2.        i::Handle<i::SharedFunctionInfo>::cast(Utils::OpenHandle(this));
+3.    i::Isolate* isolate = function_info->GetIsolate();
+4.    i::Handle<i::JSFunction> function =
+5.        isolate->factory()->NewFunctionFromSharedFunctionInfo(
+6.            function_info, isolate->native_context());
+7.    return ToApiHandle<Script>(function);
+8.  }
+```
+完成绑定后，进入`ExecuteString()`，这是执行单元的入口函数，代码如下：
+```c++
+0.  bool Shell::ExecuteString(Isolate* isolate, Local<String> source,
+1.                            Local<Value> name, PrintResult print_result,
+2.                            ReportExceptions report_exceptions,
+3.                            ProcessMessageQueue process_message_queue) {
+4.    bool success = true;
+5.    {
+6.      PerIsolateData* data = PerIsolateData::Get(isolate);
+7.      Local<Context> realm =
+8.          Local<Context>::New(isolate, data->realms_[data->realm_current_]);
+9.      Context::Scope context_scope(realm);
+10.      MaybeLocal<Script> maybe_script;
+11.      Local<Context> context(isolate->GetCurrentContext());
+12.      ScriptOrigin origin(name);
+13.      if (options.compile_options == ScriptCompiler::kConsumeCodeCache) {
+14.  //...................删除部分代码，留下最核心功能
+15.      } else if (options.stress_background_compile) {
+16.  //...................删除部分代码，留下最核心功能
+17.      } else {
+18.        ScriptCompiler::Source script_source(source, origin);
+19.        maybe_script = ScriptCompiler::Compile(context, &script_source,
+20.                                               options.compile_options);
+21.      }
+22.      maybe_result = script->Run(realm);
+23.  //...................删除部分代码，留下最核心功能
+24.      if (options.code_cache_options ==
+25.          ShellOptions::CodeCacheOptions::kProduceCacheAfterExecute) {
+26.        // Serialize and store it in memory for the next execution.
+27.        ScriptCompiler::CachedData* cached_data =
+28.            ScriptCompiler::CreateCodeCache(script->GetUnboundScript());
+29.        StoreInCodeCache(isolate, source, cached_data);
+30.        delete cached_data;
+31.      }
+32.      if (process_message_queue && !EmptyMessageQueues(isolate)) success = false;
+33.      data->realm_current_ = data->realm_switch_;
+34.    }
+35.    DCHECK(!try_catch.HasCaught());
+36.    return success;
+37.  }
+```
+上述代码中，`maybe_script`变量在上述代码中被多次重复使用，在debug时可以观察到它代表的语义多次发生变化，我们只需关注`this`指针的结果即可。19行执行完后得到`maybe_script`结果，进入22行`script->Run(realm)`，代码如下：
+```c++
+0.  MaybeLocal<Value> Script::Run(Local<Context> context) {
+1.    auto isolate = reinterpret_cast<i::Isolate*>(context->GetIsolate());
+2.    TRACE_EVENT_CALL_STATS_SCOPED(isolate, "v8", "V8.Execute");
+3.    ENTER_V8(isolate, context, Script, Run, MaybeLocal<Value>(),
+4.             InternalEscapableScope);
+5.    i::HistogramTimerScope execute_timer(isolate->counters()->execute(), true);
+6.    i::AggregatingHistogramTimerScope timer(isolate->counters()->compile_lazy());
+7.    i::TimerEventScope<i::TimerEventExecute> timer_scope(isolate);
+8.    auto fun = i::Handle<i::JSFunction>::cast(Utils::OpenHandle(this));
+9.    i::Handle<i::Object> receiver = isolate->global_proxy();
+10.    Local<Value> result;
+11.    has_pending_exception = !ToLocal<Value>(
+12.        i::Execution::Call(isolate, fun, receiver, 0, nullptr), &result);
+13.    RETURN_ON_FAILED_EXECUTION(Value);
+14.    RETURN_ESCAPED(result);
+15.  }
+```  
+上述代码中，第8行`auto fun = i::Handle<i::JSFunction>::cast(Utils::OpenHandle(this));`将`this`结果转为`JSFunction`，得到`console.log(JsPrint(6));`的fun，fun是JSFuncion类型，fun中包括了字节码序列，进入12行的`call()`方法。在`call()`方法中，执行`SetUpForCall()`完成参数的设置，最后进入`Invoke()`，代码如下：  
+```C++
+0.  V8_WARN_UNUSED_RESULT MaybeHandle<Object> Invoke(Isolate* isolate,
+1.                                                   const InvokeParams& params) {
+2.  //...................删除部分代码，留下最核心功能
+3.    Object value;
+4.    Handle<Code> code =
+5.        JSEntry(isolate, params.execution_target, params.is_construct);
+6.    {
+7.      SaveContext save(isolate);
+8.      SealHandleScope shs(isolate);
+9.      if (FLAG_clear_exceptions_on_js_entry) isolate->clear_pending_exception();
+10.      if (params.execution_target == Execution::Target::kCallable) {
+11.        // clang-format off
+12.        // {new_target}, {target}, {receiver}, return value: tagged pointers
+13.        // {argv}: pointer to array of tagged pointers
+14.        using JSEntryFunction = GeneratedCode<Address(
+15.            Address root_register_value, Address new_target, Address target,
+16.            Address receiver, intptr_t argc, Address** argv)>;
+17.        // clang-format on
+18.        JSEntryFunction stub_entry =
+19.            JSEntryFunction::FromAddress(isolate, code->InstructionStart());
+20.        Address orig_func = params.new_target->ptr();
+21.        Address func = params.target->ptr();
+22.        Address recv = params.receiver->ptr();
+23.        Address** argv = reinterpret_cast<Address**>(params.argv);
+24.        RuntimeCallTimerScope timer(isolate, RuntimeCallCounterId::kJS_Execution);
+25.        value = Object(stub_entry.Call(isolate->isolate_data()->isolate_root(),
+26.                                       orig_func, func, recv, params.argc, argv));
+27.      } else {
+28.  //...................删除部分代码，留下最核心功能     
+29.      }
+30.    }
+```  
+在`Invoke()`中，第18行获得入口`Builtin`功能，该`Builtin`的编号是40，生成函数是`Generate_JSEntry`，它的作用是为字节码执行做准备工作。第25行进入执行函数`Call()`，该函数中调用了函数指针`fn_ptr_`，该指针是第40号`Builtin`，测试样例的字节码序列是该函数的参数，目前是c++级别的调试跟踪，图1给出了调用堆栈，从`fn_ptr_`之后将进入汇编码。  
+![avatar](f1.png)  
+这之后进入汇编执行，先执行下面的`Generate_JSEntryVariant`完成执行前的准备工作，然后执行样例代码。
+```c++
+0.  void Generate_JSEntryVariant(MacroAssembler* masm, StackFrame::Type type,
+1.                               Builtins::Name entry_trampoline) {
+2.    Label invoke, handler_entry, exit;
+3.    Label not_outermost_js, not_outermost_js_2;
+4.    {  // NOLINT. Scope block confuses linter.
+5.      NoRootArrayScope uninitialized_root_register(masm);
+6.      // Set up frame.
+7.      __ pushq(rbp);
+8.      __ movq(rbp, rsp);
+9.      // Push the stack frame type.
+10.      __ Push(Immediate(StackFrame::TypeToMarker(type)));
+11.      // Reserve a slot for the context. It is filled after the root register has
+12.      // been set up.
+13.      __ AllocateStackSpace(kSystemPointerSize);
+14.      // Save callee-saved registers (X64/X32/Win64 calling conventions).
+15.      __ pushq(r12);
+16.      __ pushq(r13);
+17.      __ pushq(r14);
+18.      __ pushq(r15);
+19.  #ifdef _WIN64
+20.      __ pushq(rdi);  // Only callee save in Win64 ABI, argument in AMD64 ABI.
+21.      __ pushq(rsi);  // Only callee save in Win64 ABI, argument in AMD64 ABI.
+22.  #endif
+23.      __ pushq(rbx);
+24.  //.......................代码太长，省略很多.............................
+25.    __ ret(0);
+26.  }
+27.  }  // namespace
+28.  //==================分隔线===============================
+29.  void Builtins::Generate_JSEntry(MacroAssembler* masm) {
+30.    Generate_JSEntryVariant(masm, StackFrame::ENTRY,
+31.                            Builtins::kJSEntryTrampoline);
+32.  }
+```
+见代码30行，40号Builtin功能`JSEntry`的实现由`Generate_JSEntryVariant`负责，`Builtin`功能的分析方法参见上一篇文章，图2给出汇编代码执行的开始片段，请读者自行跟踪。  
+![avatar](f2.png)  
+图2中上面有c++源码，下面就是汇编码了。测试样例`console.log(JsPrint(6));`，在V8中`console`是一个全局功能，它的实现如下代码：
+```c++
+0.  #define RUNTIME_FUNCTION_RETURNS_TYPE(Type, InternalType, Convert, Name)      \
+1.    static V8_INLINE InternalType __RT_impl_##Name(Arguments args,              \
+2.                                                   Isolate* isolate);           \
+3.                                                                                \
+4.    V8_NOINLINE static Type Stats_##Name(int args_length, Address* args_object, \
+5.                                         Isolate* isolate) {                    \
+6.      RuntimeCallTimerScope timer(isolate, RuntimeCallCounterId::k##Name);      \
+7.      TRACE_EVENT0(TRACE_DISABLED_BY_DEFAULT("v8.runtime"),                     \
+8.                   "V8.Runtime_" #Name);                                        \
+9.      Arguments args(args_length, args_object);                                 \
+10.      return Convert(__RT_impl_##Name(args, isolate));                          \
+11.    }                                                                           \
+12.                                                                                \
+13.    Type Name(int args_length, Address* args_object, Isolate* isolate) {        \
+14.      DCHECK(isolate->context().is_null() || isolate->context().IsContext());   \
+15.      CLOBBER_DOUBLE_REGISTERS();                                               \
+16.      if (V8_UNLIKELY(TracingFlags::is_runtime_stats_enabled())) {              \
+17.        return Stats_##Name(args_length, args_object, isolate);                 \
+18.      }                                                                         \
+19.      Arguments args(args_length, args_object);                                 \
+20.      return Convert(__RT_impl_##Name(args, isolate));                          \
+21.    }                                                                           \
+22.                                                                                \
+23.    static InternalType __RT_impl_##Name(Arguments args, Isolate* isolate)
+24.  #define CONVERT_OBJECT(x) (x).ptr()
+25.  #define CONVERT_OBJECTPAIR(x) (x)
+26.  #define RUNTIME_FUNCTION(Name) \
+27.    RUNTIME_FUNCTION_RETURNS_TYPE(Address, Object, CONVERT_OBJECT, Name)
+28.  //==================分隔线===============================
+29.  //==================分隔线===============================
+30.  Object DeclareGlobals(Isolate* isolate, Handle<FixedArray> declarations,
+31.                        int flags, Handle<JSFunction> closure) {
+32.    HandleScope scope(isolate);
+33.    Handle<JSGlobalObject> global(isolate->global_object());
+34.    Handle<Context> context(isolate->context(), isolate);
+35.    Handle<FeedbackVector> feedback_vector = Handle<FeedbackVector>::null();
+36.    Handle<ClosureFeedbackCellArray> closure_feedback_cell_array =
+37.        Handle<ClosureFeedbackCellArray>::null();
+38.    if (closure->has_feedback_vector()) {
+39.      feedback_vector =
+40.          Handle<FeedbackVector>(closure->feedback_vector(), isolate);
+41.      closure_feedback_cell_array = Handle<ClosureFeedbackCellArray>(
+42.          feedback_vector->closure_feedback_cell_array(), isolate);
+43.    } else {
+44.      closure_feedback_cell_array = Handle<ClosureFeedbackCellArray>(
+45.          closure->closure_feedback_cell_array(), isolate);
+46.    }
+47.    // Traverse the name/value pairs and set the properties.
+48.    int length = declarations->length();
+49.    FOR_WITH_HANDLE_SCOPE(isolate, int, i = 0, i, i < length, i += 4, {
+50.      Handle<String> name(String::cast(declarations->get(i)), isolate);
+51.      FeedbackSlot slot(Smi::ToInt(declarations->get(i + 1)));
+52.      Handle<Object> possibly_feedback_cell_slot(declarations->get(i + 2),
+53.                                                 isolate);
+54.      Handle<Object> initial_value(declarations->get(i + 3), isolate);
+55.      bool is_var = initial_value->IsUndefined(isolate);
+56.      bool is_function = initial_value->IsSharedFunctionInfo();
+57.      DCHECK_NE(is_var, is_function);
+58.      Handle<Object> value;
+59.      if (is_function) {
+60.        DCHECK(possibly_feedback_cell_slot->IsSmi());
+61.        Handle<FeedbackCell> feedback_cell =
+62.            closure_feedback_cell_array->GetFeedbackCell(
+63.                Smi::ToInt(*possibly_feedback_cell_slot));
+64.        // Copy the function and update its context. Use it as value.
+65.        Handle<SharedFunctionInfo> shared =
+66.            Handle<SharedFunctionInfo>::cast(initial_value);
+67.        Handle<JSFunction> function =
+68.            isolate->factory()->NewFunctionFromSharedFunctionInfo(
+69.                shared, context, feedback_cell, AllocationType::kOld);
+70.        value = function;
+71.      } else {
+72.        value = isolate->factory()->undefined_value();
+73.      }
+74.      // Compute the property attributes. According to ECMA-262,
+75.      // the property must be non-configurable except in eval.
+76.      bool is_eval = DeclareGlobalsEvalFlag::decode(flags);
+77.      int attr = NONE;
+78.      if (!is_eval) attr |= DONT_DELETE;
+79.      // ES#sec-globaldeclarationinstantiation 5.d:
+80.      // If hasRestrictedGlobal is true, throw a SyntaxError exception.
+81.      Object result = DeclareGlobal(isolate, global, name, value,
+82.                                    static_cast<PropertyAttributes>(attr), is_var,
+83.                                    is_function, RedeclarationType::kSyntaxError,
+84.                                    feedback_vector, slot);
+85.      if (isolate->has_pending_exception()) return result;
+86.    });
+87.    return ReadOnlyRoots(isolate).undefined_value();
+88.  }
+89.  //==================分隔线===============================
+90.  //==================分隔线===============================
+91.  RUNTIME_FUNCTION(Runtime_DeclareGlobals) {
+92.    HandleScope scope(isolate);
+93.    DCHECK_EQ(3, args.length());
+94.    CONVERT_ARG_HANDLE_CHECKED(FixedArray, declarations, 0);
+95.    CONVERT_SMI_ARG_CHECKED(flags, 1);
+96.    CONVERT_ARG_HANDLE_CHECKED(JSFunction, closure, 2);
+97.    return DeclareGlobals(isolate, declarations, flags, closure);
+98.  }
+
+```
+`RUNTIME_FUNCTION(Runtime_DeclareGlobals)`是由宏模板定义的全局功能，该函数先检查参数的正确性，然后进入`DeclareGlobals()`完成具体功能。在我们的测试样例中，`DeclareGlobals()`是获得`console`的全局对象。得到该对象后返回到汇编码状态接着执行，获得该对象的`log`属性，也就是`console.log`，检测到它的参数`JsPrint(6)`是函数，然后编译此函数，得到一份字节码序列，开启一个新的执行单元，请读者自行跟踪。
+好了，今天到这里，下次见。   
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap10-1003/f1.png b/chap10-1003/f1.png
new file mode 100644
index 0000000..189648d
Binary files /dev/null and b/chap10-1003/f1.png differ
diff --git a/chap10-1003/f2.png b/chap10-1003/f2.png
new file mode 100644
index 0000000..a8ea9a0
Binary files /dev/null and b/chap10-1003/f2.png differ
diff --git a/chap11-1006/README.md b/chap11-1006/README.md
new file mode 100644
index 0000000..ead2384
--- /dev/null
+++ b/chap11-1006/README.md
@@ -0,0 +1,355 @@
+# 连载《Chrome V8 原理讲解》第十一篇 字节码调度 Dispatch机制
+![avatar](../v8.png)  
+
+# 1 摘要  
+
+Dispatch（调度）负责字节码的调度，每条字节码执行完后由Dispatch负责调度下一条字节码执行，相当于寄存器EIP++、执行下一条字节码。Dispatch是V8维护的全局指令调度机制，它由调度表（dispatch table）、一个物理寄存器和调度函数`Dispatch()`组成，每条字节码处理程序（Bytecode handler）执行结束后不执行下一条字节码，而是执行函数`Dispatch()`，由它负责调用下一条字节码。本文讲解Dispatch机制的源码、数据结构和`Dispatch()`调度方法。  
+
+本文内容组织方式：讲解Dispatch机制具体实现（章节2）；`Dispatch()`调度下一条字节码的源码分析（章节3）。  
+
+# 2 Dispatch机制  
+
+字节码处理程序的地址存储在`Dispatch table`中，使用物理寄存器维护。`Dispatch table`是指针数组，数组元素是`Code`类型指针，指向一个字节码处理程序。  
+
+```c++
+1.  class Code : public HeapObject {
+2.   public:
+3.    NEVER_READ_ONLY_SPACE
+4.    using Flags = uint32_t;
+5.  #define CODE_KIND_LIST(V)   \
+6.    V(OPTIMIZED_FUNCTION)     \
+7.    V(BYTECODE_HANDLER)       \
+8.    V(STUB)                   \
+9.    V(BUILTIN)                \
+10.   V(REGEXP)                 \
+11.    V(WASM_FUNCTION)          \
+12.    V(WASM_TO_CAPI_FUNCTION)  \
+13.    V(WASM_TO_JS_FUNCTION)    \
+14.    V(JS_TO_WASM_FUNCTION)    \
+15.    V(JS_TO_JS_FUNCTION)      \
+16.    V(WASM_INTERPRETER_ENTRY) \
+17.    V(C_WASM_ENTRY)
+18.    enum Kind {
+19.  #define DEFINE_CODE_KIND_ENUM(name) name,
+20.      CODE_KIND_LIST(DEFINE_CODE_KIND_ENUM)
+21.  #undef DEFINE_CODE_KIND_ENUM
+22.          NUMBER_OF_KINDS
+23.    };
+24.    static const char* Kind2String(Kind kind);
+25.  #ifdef ENABLE_DISASSEMBLER
+26.    const char* GetName(Isolate* isolate) const;
+27.    V8_EXPORT_PRIVATE void Disassemble(const char* name, std::ostream& os,
+28.                                       Address current_pc = kNullAddress);
+29.  #endif
+30.  //.................省略很多代码....................
+31.  //.................省略很多代码....................
+32.  };
+```  
+
+**注意：** 在Isolate中，还有另一个数据表，用于管理所有Builtin，表项也是`Code`类型。本文的`Dispatch table`数据表，只包含`Code`类型为`BYTECODE_HANDLER`的Builtin地址。  
+字节码调度由`Builtin`方法实现，其外层的入口函数为`BuildWithMacroAssembler()`，代码如下：  
+
+```c++
+1.  Code BuildWithMacroAssembler(Isolate* isolate, int32_t builtin_index,
+2.                               MacroAssemblerGenerator generator,
+3.                               const char* s_name) {
+4.    HandleScope scope(isolate);
+5.    // Canonicalize handles, so that we can share constant pool entries pointing
+6.    // to code targets without dereferencing their handles.
+7.    CanonicalHandleScope canonical(isolate);
+8.    constexpr int kBufferSize = 32 * KB;
+9.    byte buffer[kBufferSize];
+10.   MacroAssembler masm(isolate, BuiltinAssemblerOptions(isolate, builtin_index),
+11.                        CodeObjectRequired::kYes,
+12.                        ExternalAssemblerBuffer(buffer, kBufferSize));
+13.    masm.set_builtin_index(builtin_index);
+14.    DCHECK(!masm.has_frame());
+15.    generator(&masm);
+16.    int handler_table_offset = 0;
+17.    // JSEntry builtins are a special case and need to generate a handler table.
+18.    DCHECK_EQ(Builtins::KindOf(Builtins::kJSEntry), Builtins::ASM);
+19.    DCHECK_EQ(Builtins::KindOf(Builtins::kJSConstructEntry), Builtins::ASM);
+20.    DCHECK_EQ(Builtins::KindOf(Builtins::kJSRunMicrotasksEntry), Builtins::ASM);
+21.    if (Builtins::IsJSEntryVariant(builtin_index)) {
+22.      handler_table_offset = HandlerTable::EmitReturnTableStart(&masm);
+23.      HandlerTable::EmitReturnEntry(
+24.          &masm, 0, isolate->builtins()->js_entry_handler_offset());
+25.    }
+26.    //.....................................................
+27.    //................省略很多.............................
+28.  }
+```   
+
+`BuildWithMacroAssembler()`的分析方法参见第九篇文章，直接给出它的重要参数：`builtin_index`值为65，是Builtin编号，`generator`为`Generate_InterpreterEnterBytecodeDispatch`，下面是源码：  
+
+```c++
+1.  static void Generate_InterpreterEnterBytecode(MacroAssembler* masm) {
+2.    // Set the return address to the correct point in the interpreter entry
+3.    // trampoline.
+4.    Label builtin_trampoline, trampoline_loaded;
+5.    Smi interpreter_entry_return_pc_offset(
+6.        masm->isolate()->heap()->interpreter_entry_return_pc_offset());
+7.    DCHECK_NE(interpreter_entry_return_pc_offset, Smi::kZero);
+8.    // If the SFI function_data is an InterpreterData, the function will have a
+9.    // custom copy of the interpreter entry trampoline for profiling. If so,
+10.   // get the custom trampoline, otherwise grab the entry address of the global
+11.    // trampoline.
+12.    __ movq(rbx, Operand(rbp, StandardFrameConstants::kFunctionOffset));
+13.    __ LoadTaggedPointerField(
+14.        rbx, FieldOperand(rbx, JSFunction::kSharedFunctionInfoOffset));
+15.    __ LoadTaggedPointerField(
+16.        rbx, FieldOperand(rbx, SharedFunctionInfo::kFunctionDataOffset));
+17.    __ CmpObjectType(rbx, INTERPRETER_DATA_TYPE, kScratchRegister);
+18.    __ j(not_equal, &builtin_trampoline, Label::kNear);
+19.    __ movq(rbx,
+20.            FieldOperand(rbx, InterpreterData::kInterpreterTrampolineOffset));
+21.    __ addq(rbx, Immediate(Code::kHeaderSize - kHeapObjectTag));
+22.    __ jmp(&trampoline_loaded, Label::kNear);
+23.    __ bind(&builtin_trampoline);
+24.    // TODO(jgruber): Replace this by a lookup in the builtin entry table.
+25.    __ movq(rbx,
+26.            __ ExternalReferenceAsOperand(
+27.                ExternalReference::
+28.                    address_of_interpreter_entry_trampoline_instruction_start(
+29.                        masm->isolate()),
+30.                kScratchRegister));
+31.    __ bind(&trampoline_loaded);
+32.    __ addq(rbx, Immediate(interpreter_entry_return_pc_offset.value()));
+33.    __ Push(rbx);
+34.    // Initialize dispatch table register.
+35.    __ Move(
+36.        kInterpreterDispatchTableRegister,
+37.        ExternalReference::interpreter_dispatch_table_address(masm->isolate()));
+38.    // Get the bytecode array pointer from the frame.
+39.    __ movq(kInterpreterBytecodeArrayRegister,
+40.            Operand(rbp, InterpreterFrameConstants::kBytecodeArrayFromFp));
+41.    if (FLAG_debug_code) {
+42.      // Check function data field is actually a BytecodeArray object.
+43.      __ AssertNotSmi(kInterpreterBytecodeArrayRegister);
+44.      __ CmpObjectType(kInterpreterBytecodeArrayRegister, BYTECODE_ARRAY_TYPE,
+45.                       rbx);
+46.      __ Assert(
+47.          equal,
+48.          AbortReason::kFunctionDataShouldBeBytecodeArrayOnInterpreterEntry);
+49.    }
+50.    // Get the target bytecode offset from the frame.
+51.    __ movq(kInterpreterBytecodeOffsetRegister,
+52.            Operand(rbp, InterpreterFrameConstants::kBytecodeOffsetFromFp));
+53.    __ SmiUntag(kInterpreterBytecodeOffsetRegister,
+54.                kInterpreterBytecodeOffsetRegister);
+55.    // Dispatch to the target bytecode.
+56.    __ movzxbq(r11, Operand(kInterpreterBytecodeArrayRegister,
+57.                            kInterpreterBytecodeOffsetRegister, times_1, 0));
+58.    __ movq(kJavaScriptCallCodeStartRegister,
+59.            Operand(kInterpreterDispatchTableRegister, r11,
+60.                    times_system_pointer_size, 0));
+61.    __ jmp(kJavaScriptCallCodeStartRegister);
+62.  }
+63.  //================================分隔线=========================
+64.  //================================分隔线=========================
+65.  //================================分隔线=========================
+66.  void Builtins::Generate_InterpreterEnterBytecodeDispatch(MacroAssembler* masm) {
+67.    Generate_InterpreterEnterBytecode(masm);
+68.  }
+```  
+
+上述代码由两部分组成，`Generate_InterpreterEnterBytecodeDispatch()`是字节码调度程序的入口，`Generate_InterpreterEnterBytecode()`是调度的具体实现，下面给出几点重要概念：  
+
+**（1）** `Generate_InterpreterEnterBytecodeDispatch()`是`Builtin`方法。它的index为65号（V8版本不同，index可能略有不同）。  
+
+**（2）** V8使用物理寄存器保存`Dispatch table`地址，寄存器名字为`kInterpreterDispatchTableRegister`，在实际运行时映射到物理寄存器。使用物理寄存器可以避免指令调度时的入栈出栈，简化指令设计，提高效率。  
+
+下面解释代码的重要语句：  
+
+**（1）** 代码35行把`dispatch table`地址移动到`kInterpreterDispatchTableRegister`寄存器，`ExternalReference::interpreter_dispatch_table_address(masm->isolate())`负责从`isolate`中取出基址，`interpreter_dispatch_table_address`的源码如下：
+```c++
+1.  ExternalReference ExternalReference::interpreter_dispatch_table_address(
+2.      Isolate* isolate) {
+3.    return ExternalReference(isolate->interpreter()->dispatch_table_address());
+4.  }
+5.  //================================分隔线=========================
+6.    interpreter::Interpreter* interpreter() const {
+7.      return interpreter_;
+8.    }
+9.  //================================分隔线=========================
+10.   Address dispatch_table_address() {
+11.      return reinterpret_cast<Address>(&dispatch_table_[0]);
+12.    }
+```  
+
+上述代码，可以看到`dispatch_table_`是数组，基址是`&dispatch_table_[0]`,它的位置是`isolate->interpreter_->dispatch_table_`。
+
+**（2）** 代码39行从堆栈中获取bytecode array的基址。  
+
+**（3）** 代码51行获取目标bytecode的偏移量（offset）。  
+
+**（4）** 代码56、58行，计算目标bytecode地址，存入`kJavaScriptCallCodeStartRegister`。  
+
+**（5）** 代码61行，跳转到`kJavaScriptCallCodeStartRegister`，调度完毕，图1为函数调用堆栈。  
+
+![avatar](f1.png)  
+
+# 3 Dispatch()方法  
+
+`Dispatch()`是字节码处理程序最后调用的方法，故称之为尾部调用（TailCall）方法，下面给出几条字节码处理程序源码：  
+
+```c++
+1.  // StaGlobal <name_index> <slot>
+2.  //
+3.  // Store the value in the accumulator into the global with name in constant pool
+4.  // entry <name_index> using FeedBackVector slot <slot>.
+5.  IGNITION_HANDLER(StaGlobal, InterpreterAssembler) {
+6.    TNode<Context> context = GetContext();
+7.    // Store the global via the StoreGlobalIC.
+8.    TNode<Name> name = CAST(LoadConstantPoolEntryAtOperandIndex(0));
+9.    TNode<Object> value = GetAccumulator();
+10.   TNode<IntPtrT> raw_slot = Signed(BytecodeOperandIdx(1));
+11.    TNode<Smi> smi_slot = SmiTag(raw_slot);
+12.    TNode<HeapObject> maybe_vector = LoadFeedbackVector();
+13.    Label no_feedback(this, Label::kDeferred), end(this);
+14.    GotoIf(IsUndefined(maybe_vector), &no_feedback);
+15.    CallBuiltin(Builtins::kStoreGlobalIC, context, name, value, smi_slot,
+16.                maybe_vector);
+17.    Goto(&end);
+18.    Bind(&no_feedback);
+19.    CallRuntime(Runtime::kStoreGlobalICNoFeedback_Miss, context, value, name);
+20.    Goto(&end);
+21.    Bind(&end);
+22.    Dispatch();
+23.  }
+24.  // LdaContextSlot <context> <slot_index> <depth>
+25.  //
+26.  // Load the object in |slot_index| of the context at |depth| in the context
+27.  // chain starting at |context| into the accumulator.
+28.  IGNITION_HANDLER(LdaContextSlot, InterpreterAssembler) {
+29.    TNode<Context> context = CAST(LoadRegisterAtOperandIndex(0));
+30.    TNode<IntPtrT> slot_index = Signed(BytecodeOperandIdx(1));
+31.    TNode<Uint32T> depth = BytecodeOperandUImm(2);
+32.    TNode<Context> slot_context = GetContextAtDepth(context, depth);
+33.    TNode<Object> result = LoadContextElement(slot_context, slot_index);
+34.    SetAccumulator(result);
+35.    Dispatch();
+36.  }
+37.  // LdaImmutableContextSlot <context> <slot_index> <depth>
+38.  //
+39.  // Load the object in |slot_index| of the context at |depth| in the context
+40.  // chain starting at |context| into the accumulator.
+41.  IGNITION_HANDLER(LdaImmutableContextSlot, InterpreterAssembler) {
+42.    TNode<Context> context = CAST(LoadRegisterAtOperandIndex(0));
+43.    TNode<IntPtrT> slot_index = Signed(BytecodeOperandIdx(1));
+44.    TNode<Uint32T> depth = BytecodeOperandUImm(2);
+45.    TNode<Context> slot_context = GetContextAtDepth(context, depth);
+46.    TNode<Object> result = LoadContextElement(slot_context, slot_index);
+47.    SetAccumulator(result);
+48.    Dispatch();
+49.  }
+```
+上述代码给出了三条字节码处理程序，它们的尾部都调用了`Dispatch()`方法。下面给出`Dispatch()`源码，并解释重要语句。  
+
+```C++
+1.  void InterpreterAssembler::Dispatch() {
+2.    Comment("========= Dispatch");
+3.    DCHECK_IMPLIES(Bytecodes::MakesCallAlongCriticalPath(bytecode_), made_call_);
+4.    TNode<IntPtrT> target_offset = Advance();
+5.    TNode<WordT> target_bytecode = LoadBytecode(target_offset);
+6.    if (Bytecodes::IsStarLookahead(bytecode_, operand_scale_)) {
+7.      target_bytecode = StarDispatchLookahead(target_bytecode);
+8.    }
+9.    DispatchToBytecode(target_bytecode, BytecodeOffset());
+10. }
+```  
+第2行代码是注释功能，调试代码时很有用；第4行`Advance()`是获取目标字节码在`bytecode array`中的偏移量，请读者自行分析；第5行读取目标字节码；第9行进入`DispatchToBytecode()`，该方法又进入`DispatchToBytecodeHandlerEntry()`，代码如下：  
+
+```c++
+void InterpreterAssembler::DispatchToBytecodeHandlerEntry(
+    TNode<RawPtrT> handler_entry, TNode<IntPtrT> bytecode_offset) {
+  // Propagate speculation poisoning.
+  TNode<RawPtrT> poisoned_handler_entry =
+      UncheckedCast<RawPtrT>(WordPoisonOnSpeculation(handler_entry));
+  TailCallBytecodeDispatch(InterpreterDispatchDescriptor{},
+                           poisoned_handler_entry, GetAccumulatorUnchecked(),
+                           bytecode_offset, BytecodeArrayTaggedPointer(),
+                           DispatchTablePointer());
+}
+```
+该方法的参数1是目标字节码，它的作用是从`dispatch table`中索引对应的字节码处理程序；参数2是目标字节码的偏移量，它的作用是从`bytecode array`中读取操作数，下面进入`TailCallBytecodeDispatch()`:  
+
+```c++
+0.  template <class... TArgs>
+1.  void CodeAssembler::TailCallBytecodeDispatch(
+2.      const CallInterfaceDescriptor& descriptor, TNode<RawPtrT> target,
+3.      TArgs... args) {
+4.    DCHECK_EQ(descriptor.GetParameterCount(), sizeof...(args));
+5.    auto call_descriptor = Linkage::GetBytecodeDispatchCallDescriptor(
+6.        zone(), descriptor, descriptor.GetStackParameterCount());
+7.    Node* nodes[] = {target, args...};
+8.    CHECK_EQ(descriptor.GetParameterCount() + 1, arraysize(nodes));
+9.    raw_assembler()->TailCallN(call_descriptor, arraysize(nodes), nodes);
+10.  }
+```  
+代码第5行建立目标字节码的`call discriptor`，见下面代码：  
+
+```c++
+0.  CallDescriptor* Linkage::GetBytecodeDispatchCallDescriptor(
+1.      Zone* zone, const CallInterfaceDescriptor& descriptor,
+2.      int stack_parameter_count) {
+3.    const int register_parameter_count = descriptor.GetRegisterParameterCount();
+4.    const int parameter_count = register_parameter_count + stack_parameter_count;
+5.    DCHECK_EQ(descriptor.GetReturnCount(), 1);
+6.    LocationSignature::Builder locations(zone, 1, parameter_count);
+7.    locations.AddReturn(regloc(kReturnRegister0, descriptor.GetReturnType(0)));
+8.    for (int i = 0; i < parameter_count; i++) {
+9.      if (i < register_parameter_count) {
+10.        // The first parameters go in registers.
+11.        Register reg = descriptor.GetRegisterParameter(i);
+12.        MachineType type = descriptor.GetParameterType(i);
+13.        locations.AddParam(regloc(reg, type));
+14.      } else {
+15.        int stack_slot = i - register_parameter_count - stack_parameter_count;
+16.        locations.AddParam(LinkageLocation::ForCallerFrameSlot(
+17.            stack_slot, MachineType::AnyTagged()));
+18.      }
+19.    }
+20.    MachineType target_type = MachineType::Pointer();
+21.    LinkageLocation target_loc = LinkageLocation::ForAnyRegister(target_type);
+22.    const CallDescriptor::Flags kFlags =
+23.        CallDescriptor::kCanUseRoots | CallDescriptor::kFixedTargetRegister;
+24.    return new (zone) CallDescriptor(  // --
+25.        CallDescriptor::kCallAddress,  // kind
+26.        target_type,                   // target MachineType
+27.        target_loc,                    // target location
+28.        locations.Build(),             // location_sig
+29.        stack_parameter_count,         // stack_parameter_count
+30.        Operator::kNoProperties,       // properties
+31.        kNoCalleeSaved,                // callee-saved registers
+32.        kNoCalleeSaved,                // callee-saved fp
+33.        kFlags,                        // flags
+34.        descriptor.DebugName());
+35.  }
+```  
+
+这个函数的参数2是目标字节码，参数3是栈参数的数量，函数的作用是申请寄存器等资源、生成`CallDescriptor`。`CallDescriptor`描述了调用字节码时应该提供的参数类型、数量等，代码24行的注释给出了它的布局。  
+
+返回`TailCallBytecodeDispatch()`，第9行`raw_assembler()->TailCallN()`的第一个参数是`CallDescriptor`，源码下如:  
+
+```c++
+1.  void RawMachineAssembler::TailCallN(CallDescriptor* call_descriptor,
+2.                                      int input_count, Node* const* inputs) {
+3.    // +1 is for target.
+4.    DCHECK_EQ(input_count, call_descriptor->ParameterCount() + 1);
+5.    Node* tail_call =
+6.        MakeNode(common()->TailCall(call_descriptor), input_count, inputs);
+7.    schedule()->AddTailCall(CurrentBlock(), tail_call);
+8.    current_block_ = nullptr;
+9.  }
+```  
+第5行生成`Node`节点，第7行由`AddTailCall()`把节点加到当前基本块（Basic Block）的尾部，完成字节码调度，`AddTailCall()`源码请读者自行分析，图2给出了上述过程的调用堆栈。  
+
+![avatar](f2.png)  
+
+学习过程中，需要分析和调试汇编码，思路一旦中断就可能得从头再来，一定要多做笔记。  
+
+好了，今天到这里，下次见。   
+
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap11-1006/f1.png b/chap11-1006/f1.png
new file mode 100644
index 0000000..159a00e
Binary files /dev/null and b/chap11-1006/f1.png differ
diff --git a/chap11-1006/f2.png b/chap11-1006/f2.png
new file mode 100644
index 0000000..8f2fb66
Binary files /dev/null and b/chap11-1006/f2.png differ
diff --git a/chap12-1009/README.md b/chap12-1009/README.md
new file mode 100644
index 0000000..43979cb
--- /dev/null
+++ b/chap12-1009/README.md
@@ -0,0 +1,296 @@
+# 《Chrome V8原理讲解》第十二篇 JSFunction源码分析
+![avatar](../v8.png)  
+
+# 1 摘要  
+编译Javascript源码得到的字节码流（Bytecode Array）不能直接执行，绑定了入口（Entry）和上下文（Context）的字节码流才能被解释器（Ignition）执行，绑定了“入口+上下文”的字码流称为JSFunction，JSFunction是Ignition可以执行的实例。读懂JSFunction，可以更加深入了解Igntion的工作原理，更有助于在脑海中、在演草纸上擘画出字节码的解释（interpreter）过程。本文以SharedFunction（字节码流的表示方法）为输入，讲解JSFuncition源码和重要功能函数，分析JSFunction创建（new）、绑定入口和上下文的过程（章节2）；最后，分析JSFunction内存布局，讲解读/写（getter/setter）方法（章节3）。
+
+# 2 JSFunction分析  
+一段C语言程序要经过编译（Compilation）、汇编（Assembly）和链接（Linking）之后才能执行。不太严谨但很形象的类比：字节码流类似汇编之后的结果（V8称之为SharedFunction），JSFunction类似链接之后的程序，所以说JSFunction是可以执行的实例。下面来看JSFunction源码：  
+```c++
+1.  class JSFunction : public JSObject {
+2.    public:
+3.     DECL_ACCESSORS(prototype_or_initial_map, HeapObject)
+4.     DECL_ACCESSORS(shared, SharedFunctionInfo)
+5.     static const int kLengthDescriptorIndex = 0;
+6.     static const int kNameDescriptorIndex = 1;
+7.     static const int kMaybeHomeObjectDescriptorIndex = 2;
+8.     inline Context context();
+9.     inline bool has_context() const;
+10.    inline void set_context(HeapObject context);
+11.    inline JSGlobalProxy global_proxy();
+12.    inline NativeContext native_context();
+13.    inline int length();
+14.    static Handle<Object> GetName(Isolate* isolate, Handle<JSFunction> function);
+15.    static Handle<NativeContext> GetFunctionRealm(Handle<JSFunction> function);
+16.    inline Code code() const;
+17.    inline void set_code(Code code);
+18.    inline void set_code_no_write_barrier(Code code);
+19.    inline AbstractCode abstract_code();
+20.    inline bool IsInterpreted();
+21.    inline bool ChecksOptimizationMarker();
+22.    inline bool IsOptimized();
+23.    inline bool HasOptimizedCode();
+24.    inline bool HasOptimizationMarker();
+25.    void MarkForOptimization(ConcurrencyMode mode);
+26.    inline bool IsMarkedForOptimization();
+27.    inline bool IsMarkedForConcurrentOptimization();
+28.    inline bool IsInOptimizationQueue();
+29.    inline void ClearOptimizedCodeSlot(const char* reason);
+30.    inline void SetOptimizationMarker(OptimizationMarker marker);
+31.    inline void ClearOptimizationMarker();
+32.    int ComputeInstanceSizeWithMinSlack(Isolate* isolate);
+33.    inline void CompleteInobjectSlackTrackingIfActive();
+34.    DECL_ACCESSORS(raw_feedback_cell, FeedbackCell)
+35.    inline FeedbackVector feedback_vector() const;
+36.    inline bool has_feedback_vector() const;
+37.    V8_EXPORT_PRIVATE static void EnsureFeedbackVector(
+38.        Handle<JSFunction> function);
+39.    inline bool has_closure_feedback_cell_array() const;
+40.    inline ClosureFeedbackCellArray closure_feedback_cell_array() const;
+41.    static void EnsureClosureFeedbackCellArray(Handle<JSFunction> function);
+42.    static void InitializeFeedbackCell(Handle<JSFunction> function);
+43.    void ClearTypeFeedbackInfo();
+44.    inline bool NeedsResetDueToFlushedBytecode();
+45.    inline void ResetIfBytecodeFlushed();
+46.    DECL_GETTER(has_prototype_slot, bool)
+47.    DECL_GETTER(initial_map, Map)
+48.    static void SetInitialMap(Handle<JSFunction> function, Handle<Map> map,
+49.                              Handle<HeapObject> prototype);
+50.    DECL_GETTER(has_initial_map, bool)
+51.    V8_EXPORT_PRIVATE static void EnsureHasInitialMap(
+52.        Handle<JSFunction> function);
+53.    static V8_WARN_UNUSED_RESULT MaybeHandle<Map> GetDerivedMap(
+54.        Isolate* isolate, Handle<JSFunction> constructor,
+55.        Handle<JSReceiver> new_target);
+56.    DECL_GETTER(has_prototype, bool)
+57.    DECL_GETTER(has_instance_prototype, bool)
+58.    DECL_GETTER(prototype, Object)
+59.    DECL_GETTER(instance_prototype, HeapObject)
+60.    DECL_GETTER(has_prototype_property, bool)
+61.    DECL_GETTER(PrototypeRequiresRuntimeLookup, bool)
+62.    static void SetPrototype(Handle<JSFunction> function, Handle<Object> value);
+63.    inline bool is_compiled() const;
+64.    static int GetHeaderSize(bool function_has_prototype_slot) {
+65.      return function_has_prototype_slot ? JSFunction::kSizeWithPrototype
+66.                                         : JSFunction::kSizeWithoutPrototype;
+67.    }
+68.    void PrintName(FILE* out = stdout);
+69.    DECL_CAST(JSFunction)
+70.    static V8_WARN_UNUSED_RESULT int CalculateExpectedNofProperties(
+71.        Isolate* isolate, Handle<JSFunction> function);
+72.    static void CalculateInstanceSizeHelper(InstanceType instance_type,
+73.                                            bool has_prototype_slot,
+74.                                            int requested_embedder_fields,
+75.                                            int requested_in_object_properties,
+76.                                            int* instance_size,
+77.                                            int* in_object_properties);
+78.    DECL_PRINTER(JSFunction)
+79.    DECL_VERIFIER(JSFunction)
+80.    static Handle<String> GetName(Handle<JSFunction> function);
+81.    static V8_WARN_UNUSED_RESULT bool SetName(Handle<JSFunction> function,
+82.                                              Handle<Name> name,
+83.                                              Handle<String> prefix);
+84.    static Handle<String> GetDebugName(Handle<JSFunction> function);
+85.    static Handle<String> ToString(Handle<JSFunction> function);
+86.  //
+87.    DEFINE_FIELD_OFFSET_CONSTANTS(JSObject::kHeaderSize,
+88.                                  TORQUE_GENERATED_JSFUNCTION_FIELDS)
+89.    static constexpr int kSizeWithoutPrototype = kPrototypeOrInitialMapOffset;
+90.    static constexpr int kSizeWithPrototype = kSize;
+91.    OBJECT_CONSTRUCTORS(JSFunction, JSObject);
+92.  };
+```  
+代码18~45行是关于优化及反优化的功能，这些优化机制用于热点统计，反馈给TurboFan用于优化编译；46~68行定义了`GETTER`方法。5~7行定义了几个重要的数据索引（index）；10，11，12行代码绑定上下文和全局Reciver；17行代码绑定入口的Builtin功能（InterpreterEntryTrampoline），87行是JSFunction的内存布局，下面跟随new JSFunction过程逐步分析:  
+**（1）** 获得SharedFunction  
+```c++
+1.  void InstallBytecodeArray(Handle<BytecodeArray> bytecode_array,
+2.                            Handle<SharedFunctionInfo> shared_info,
+3.                            ParseInfo* parse_info, Isolate* isolate) {
+4.    if (!FLAG_interpreted_frames_native_stack) {
+5.      shared_info->set_bytecode_array(*bytecode_array);
+6.      return;
+7.    }
+8.    Handle<Code> code = isolate->factory()->CopyCode(Handle<Code>::cast(
+9.        isolate->factory()->interpreter_entry_trampoline_for_profiling()));
+10.    Handle<InterpreterData> interpreter_data =
+11.        Handle<InterpreterData>::cast(isolate->factory()->NewStruct(
+12.            INTERPRETER_DATA_TYPE, AllocationType::kOld));
+13.    interpreter_data->set_bytecode_array(*bytecode_array);
+14.    interpreter_data->set_interpreter_trampoline(*code);
+15.    shared_info->set_interpreter_data(*interpreter_data);
+16.    Handle<Script> script = parse_info->script();
+17.    Handle<AbstractCode> abstract_code = Handle<AbstractCode>::cast(code);
+18.    int line_num =
+19.        Script::GetLineNumber(script, shared_info->StartPosition()) + 1;
+20.    int column_num =
+21.        Script::GetColumnNumber(script, shared_info->StartPosition()) + 1;
+22.    String script_name = script->name().IsString()
+23.                             ? String::cast(script->name())
+24.                             : ReadOnlyRoots(isolate).empty_string();
+25.    CodeEventListener::LogEventsAndTags log_tag = Logger::ToNativeByScript(
+26.        CodeEventListener::INTERPRETED_FUNCTION_TAG, *script);
+27.    PROFILE(isolate, CodeCreateEvent(log_tag, *abstract_code, *shared_info,
+28.                                     script_name, line_num, column_num));
+29.  }
+```  
+`InstallBytecodeArray()`最重要的作用是把编译生成的`bytecode_array`安装到shared_info中，代码第5行。**注：** 我的编译选项：FLAG_interpreted_frames_native_stack为`false`。  
+**（2）** 生成JSFunction  
+```c++
+1.  Local<Script> UnboundScript::BindToCurrentContext() {
+2.    auto function_info =
+3.        i::Handle<i::SharedFunctionInfo>::cast(Utils::OpenHandle(this));
+4.    i::Isolate* isolate = function_info->GetIsolate();
+5.    i::Handle<i::JSFunction> function =
+6.        isolate->factory()->NewFunctionFromSharedFunctionInfo(
+7.            function_info, isolate->native_context());
+8.    return ToApiHandle<Script>(function);
+9.  }
+10.  //..................分隔线........................................
+11.  Handle<JSFunction> Factory::NewFunctionFromSharedFunctionInfo(
+12.      Handle<Map> initial_map, Handle<SharedFunctionInfo> info,
+13.      Handle<Context> context, AllocationType allocation) {
+14.    DCHECK_EQ(JS_FUNCTION_TYPE, initial_map->instance_type());
+15.    Handle<JSFunction> result =
+16.        NewFunction(initial_map, info, context, allocation);
+17.    // Give compiler a chance to pre-initialize.
+18.    Compiler::PostInstantiation(result);
+19.    return result;
+20.  }
+```  
+上述代码2行`this`转为`SharedFunctionInfo`，代码5行，`function_info`和`native_context`作为参数，返回`JSFunction`。代码5行的工厂方法`factory()`进入代码11行的`NewFunctionFromSharedFunctionInfo()`，最终调用下面的方法：  
+```c++
+1.  Handle<JSFunction> Factory::NewFunction(Handle<Map> map,
+2.                                          Handle<SharedFunctionInfo> info,
+3.                                          Handle<Context> context,
+4.                                          AllocationType allocation) {
+5.    Handle<JSFunction> function(JSFunction::cast(New(map, allocation)),
+6.                                isolate());
+7.    function->initialize_properties(isolate());
+8.    function->initialize_elements();
+9.    function->set_shared(*info);
+10.    function->set_code(info->GetCode());
+11.    function->set_context(*context);
+12.    function->set_raw_feedback_cell(*many_closures_cell());
+13.    int header_size;
+14.    if (map->has_prototype_slot()) {
+15.      header_size = JSFunction::kSizeWithPrototype;
+16.      function->set_prototype_or_initial_map(*the_hole_value());
+17.    } else {
+18.      header_size = JSFunction::kSizeWithoutPrototype;
+19.    }
+20.    InitializeJSObjectBody(function, map, header_size);
+21.    return function;
+22.  }
+```
+上述代码9行，把`SharedFunctionInfo`保存到`kSharedFunctionInfoOffset`位置。代码10行，`GetCode()`源码如下：  
+```c++
+1.  Code SharedFunctionInfo::GetCode() const {
+2.    Isolate* isolate = GetIsolate();
+3.    Object data = function_data();
+4.    if (data.IsSmi()) {
+5.      DCHECK(HasBuiltinId());
+6.      return isolate->builtins()->builtin(builtin_id());
+7.    } else if (data.IsBytecodeArray()) {
+8.      DCHECK(HasBytecodeArray());
+9.      return isolate->builtins()->builtin(Builtins::kInterpreterEntryTrampoline);
+10.    } else if (data.IsAsmWasmData()) {
+11.      DCHECK(HasAsmWasmData());
+12.      return isolate->builtins()->builtin(Builtins::kInstantiateAsmJs);
+13.    } else if (data.IsUncompiledData()) {
+14.      DCHECK(HasUncompiledData());
+15.      return isolate->builtins()->builtin(Builtins::kCompileLazy);
+16.    } else if (data.IsFunctionTemplateInfo()) {
+17.      DCHECK(IsApiFunction());
+18.      return isolate->builtins()->builtin(Builtins::kHandleApiCall);
+19.    } else if (data.IsWasmExportedFunctionData()) {
+20.      DCHECK(HasWasmExportedFunctionData());
+21.      return wasm_exported_function_data().wrapper_code();
+22.    } else if (data.IsInterpreterData()) {
+23.      Code code = InterpreterTrampoline();
+24.      DCHECK(code.IsCode());
+25.      DCHECK(code.is_interpreter_trampoline_builtin());
+26.      return code;
+27.    } else if (data.IsWasmJSFunctionData()) {
+28.      return wasm_js_function_data().wrapper_code();
+29.    } else if (data.IsWasmCapiFunctionData()) {
+30.      return wasm_capi_function_data().wrapper_code();
+31.    }
+32.    UNREACHABLE();
+33.  }
+```  
+上述代码中，我们的测试用例满足代码7行，所以得到`Builtins::kInterpreterEntryTrampoline`，它负责堆栈，压入参数等等（参见第八篇文章），即前面提到的绑定入口(Entry)。  
+返回到`NewFunction()`，11行绑定Context。至此，字节码流，入口、上下文三个最重要的数据都安装到了`function`中，new JSFunction完成，图1给出函数调用堆栈。注:map机制，JSObject后续文章讲解。  
+![avatar](f1.png)  
+# 3 JSFunction内存布局  
+
+下面讲解JSFuncion的内存布局，JSFunction是堆对象，它的成员都有固定的存储偏移（offset），`class JSFunction`中的`DEFINE_FIELD_OFFSET_CONSTANTS`宏模板定义了JSFuncion成员的封装方法，源码如下：    
+```c++
+#define TORQUE_GENERATED_JSFUNCTION_FIELDS(V) \
+V(kStartOfStrongFieldsOffset, 0) \
+V(kSharedFunctionInfoOffset, kTaggedSize) \
+V(kContextOffset, kTaggedSize) \
+V(kFeedbackCellOffset, kTaggedSize) \
+V(kEndOfStrongFieldsOffset, 0) \
+V(kStartOfWeakFieldsOffset, 0) \
+V(kCodeOffset, kTaggedSize) \
+V(kPrototypeOrInitialMapOffset, kTaggedSize) \
+V(kEndOfWeakFieldsOffset, 0) \
+V(kSize, 0) \
+//.................分隔.....................
+#define DEFINE_ONE_FIELD_OFFSET(Name, Size) Name, Name##End = Name + (Size)-1,
+
+#define DEFINE_FIELD_OFFSET_CONSTANTS(StartOffset, LIST_MACRO) \
+  enum {                                                       \
+    LIST_MACRO##_StartOffset = StartOffset - 1,                \
+    LIST_MACRO(DEFINE_ONE_FIELD_OFFSET)                        \
+  };
+```  
+`TORQUE_GENERATED_JSFUNCTION_FIELDS`定义了所有成员的存储偏移，StartOffset是`kHeaderSize`，它是基址，通过基址+偏移的方法实现读/写成员，以JSFunction的set_code为例讲解，代码如下:  
+```c++
+void JSFunction::set_code(Code value) {
+  DCHECK(!ObjectInYoungGeneration(value));
+  RELAXED_WRITE_FIELD(*this, kCodeOffset, value);
+#ifndef V8_DISABLE_WRITE_BARRIERS
+  MarkingBarrier(*this, RawField(kCodeOffset), value);
+#endif
+}
+```  
+代码中`RELAXED_WRITE_FIELD`模板的展开如下：  
+```c++
+#define RELAXED_WRITE_FIELD(p, offset, value) \
+  TaggedField<Object>::Relaxed_Store(p, offset, value)
+//.................分隔线...........................
+template <typename T, int kFieldOffset>
+void TaggedField<T, kFieldOffset>::Relaxed_Store(HeapObject host, int offset,
+                                                 T value) {
+  AsAtomicTagged::Relaxed_Store(location(host, offset),
+                                full_to_tagged(value.ptr()));
+}
+//.................分隔线...........................
+  template <typename T>
+  static void Relaxed_Store(T* addr,
+                            typename std::remove_reference<T>::type new_value) {
+    STATIC_ASSERT(sizeof(T) <= sizeof(AtomicStorageType));
+    base::Relaxed_Store(to_storage_addr(addr),
+                        cast_helper<T>::to_storage_type(new_value));
+  }
+```  
+两个`Relaxed_Store()`配合上述的宏模板实现`set_code()`的写入功能，图2给出函数调用堆栈。    
+![avatar](f2.png)  
+读数据与写数据的方式相同，在正确的偏移位置读取数据，并用类型转换获取正确内容，下面给关键代码，请读者自行分析。  
+```c++
+#define RELAXED_READ_FIELD(p, offset) \
+  TaggedField<Object>::Relaxed_Load(p, offset)
+//.................分隔线...........................
+  template <typename T>
+  static T Relaxed_Load(T* addr) {
+    STATIC_ASSERT(sizeof(T) <= sizeof(AtomicStorageType));
+    return cast_helper<T>::to_return_type(
+        base::Relaxed_Load(to_storage_addr(addr)));
+  }
+```  
+上面给出的`Relaxed_Load()`方法是公共方法，通过图2的堆栈可以看出他们是V8的基类方法，堆上对象的方法都会用这几个方法。  
+好了，今天到这里，下次见。   
+
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap12-1009/f1.png b/chap12-1009/f1.png
new file mode 100644
index 0000000..560f051
Binary files /dev/null and b/chap12-1009/f1.png differ
diff --git a/chap12-1009/f2.png b/chap12-1009/f2.png
new file mode 100644
index 0000000..9506db5
Binary files /dev/null and b/chap12-1009/f2.png differ
diff --git a/chap13-1020/README.md b/chap13-1020/README.md
new file mode 100644
index 0000000..0c92c00
--- /dev/null
+++ b/chap13-1020/README.md
@@ -0,0 +1,256 @@
+# 《Chrome V8原理讲解》第13篇 String类方法的源码分析
+
+![avatar](../v8.png)  
+# 1 摘要  
+Javascript对象是属性和一些成员值的集合。通过“.”符号来引用属性值。字符串（string）不是对象，为什么它会有属性呢？因为引用字符串的属性时，V8会将字符串转换成对象，此时对象就有了操作字符串的方法，这一转换过程对Javascript开发人员不可见，通过分析V8源码可以清楚细看这一过程，可以更好地理解Javascript中String类型的行为和特点。本文详细讲解V8中字符串相关的源码，对字符串的定义方法（章节2），字符串对象转换及重要数据结构（章节3）进行说明。最后进行技术总结，并介绍本文使用的V8调式手段(章节4)。  
+# 2 字符串String定义  
+在《Javascript:The Definitive Guide》书中提到：“字符串不是对象，它为什么有属性？”见下面代码。
+```c++
+var s = "hello world!";
+var word = s.substring(s.indexOf(" ")+1,s.length);
+console.log(word)
+```
+书中给出的答案是：“只要引用了字符串s的属性，Javascript会将字符值转换成对象--new String(s)”。我们知道，转换过程是由V8完成，为了看懂这一转换过程，我将其拆解成以下两个问题进行回答：  
+**（1）** 要先确定这个字符串s定义时的类型是简单的字符串，还是对象？如果定义时已经是对象类型，“.”操作时还需要转换吗？  
+**（2）** 如果需要转换，它一定发生在代码运行期。那么，只有跟踪字节码的运行，才能看到转换过程。  
+如下是这段JS源码对应的字节码，我们先来确定字符串s定义后的类型是什么，即回答问题1。  
+```c++
+1.  [generated bytecode for function:  (0x03d78d381bd1 <SharedFunctionInfo>)]
+2.  Parameter count 1
+3.  Register count 6
+4.  Frame size 48
+5.           000003D78D381D06 @    0 : 12 00             LdaConstant [0]
+6.           000003D78D381D08 @    2 : 26 fa             Star r1
+7.           000003D78D381D0A @    4 : 0b                LdaZero
+8.           000003D78D381D0B @    5 : 26 f9             Star r2
+9.           000003D78D381D0D @    7 : 27 fe f8          Mov <closure>, r3
+10.           000003D78D381D10 @   10 : 61 2d 01 fa 03    CallRuntime [DeclareGlobals], r1-r3
+11.      0 E> 000003D78D381D15 @   15 : a7                StackCheck
+12.      8 S> 000003D78D381D16 @   16 : 12 01             LdaConstant [1]
+13.      8 E> 000003D78D381D18 @   18 : 15 02 04          StaGlobal [2], [4]
+14.     36 S> 000003D78D381D1B @   21 : 13 02 00          LdaGlobal [2], [0]
+15.           000003D78D381D1E @   24 : 26 f9             Star r2
+16.     38 E> 000003D78D381D20 @   26 : 29 f9 03          LdaNamedPropertyNoFeedback r2, [3]
+17.           000003D78D381D23 @   29 : 26 fa             Star r1
+18.     48 E> 000003D78D381D25 @   31 : 13 02 00          LdaGlobal [2], [0]
+19.           000003D78D381D28 @   34 : 26 f7             Star r4
+20.     50 E> 000003D78D381D2A @   36 : 29 f7 04          LdaNamedPropertyNoFeedback r4, [4]
+21.           000003D78D381D2D @   39 : 26 f8             Star r3
+22.           000003D78D381D2F @   41 : 12 05             LdaConstant [5]
+23.           000003D78D381D31 @   43 : 26 f6             Star r5
+24.     50 E> 000003D78D381D33 @   45 : 5f f8 f7 02       CallNoFeedback r3, r4-r5
+25.     62 E> 000003D78D381D37 @   49 : 40 01 06          AddSmi [1], [6]
+26.           000003D78D381D3A @   52 : 26 f8             Star r3
+27.     65 E> 000003D78D381D3C @   54 : 13 02 00          LdaGlobal [2], [0]
+28.           000003D78D381D3F @   57 : 26 f7             Star r4
+29.     67 E> 000003D78D381D41 @   59 : 29 f7 06          LdaNamedPropertyNoFeedback r4, [6]
+30.           000003D78D381D44 @   62 : 26 f7             Star r4
+31.  //省略很多.................
+32.  Constant pool (size = 10)
+33.  000003D78D381C71: [FixedArray] in OldSpace
+34.   - map: 0x03ac45880169 <Map>
+35.   - length: 10
+36.             0: 0x03d78d381c11 <FixedArray[8]>
+37.             1: 0x03d78d381b69 <String[#12]: hello world!>
+38.             2: 0x03d78d381b51 <String[#1]: s>
+39.             3: 0x02ed266ea9e9 <String[#9]: substring>
+40.             4: 0x02ed266e8121 <String[#7]: indexOf>
+41.             5: 0x006d3e183c21 <String[#1]:  >
+42.             6: 0x03ac45884819 <String[#6]: length>
+43.             7: 0x03ac45885301 <String[#4]: word>
+44.             8: 0x02ed266f2441 <String[#7]: console>
+45.             9: 0x02ed266f1a81 <String[#3]: log>
+46.  Handler Table (size = 0)
+```  
+先说明一个概念`Constant pool`，常量池（代码32行至结尾），在Javascript编译期生成，用于存储常量数据的一个字符串类型数组，代码32行开始是长常池，代码37行存储Javascript源码中的`hello world!`，代码38行存储字符串变量名`s`。字节码执行过程中，常量池为其提供数据，字节码通过下标对常量池进行访问。  
+解答问题（1）字符串s定义时的类型是什么？  
+`var s = "hello world!";`，由代码12，13行完成全局字符串s的定义。代码12行`LdaConstant [1]`把常量池中下标为1的元素`hello world!`（代码37行）加载到累加器；代码13行`StaGlobal [2], [4]`以常量池[2]（代码38行）中的值（s）作为key，把累加器值存为全局变量，也就是`s = hello world!`。  
+debug跟踪这两条字节码的执行过程，可以看s定义后的类型，分析13行的字节码，得知它最终调用如下代码：  
+```c++
+RUNTIME_FUNCTION(Runtime_StoreGlobalICNoFeedback_Miss) {
+  HandleScope scope(isolate);
+  DCHECK_EQ(2, args.length());
+  // Runtime functions don't follow the IC's calling convention.
+  Handle<Object> value = args.at(0);
+  Handle<Name> key = args.at<Name>(1);
+
+  // TODO(mythria): Replace StoreGlobalStrict/Sloppy with StoreNamed.
+  StoreGlobalIC ic(isolate, Handle<FeedbackVector>(), FeedbackSlot(),
+                   FeedbackSlotKind::kStoreGlobalStrict);
+  RETURN_RESULT_OR_FAILURE(isolate, ic.Store(key, value));
+}
+//.................分隔线...................................
+#define RETURN_RESULT_OR_FAILURE(isolate, call)      \
+  do {                                               \
+    Handle<Object> __result__;                       \
+    Isolate* __isolate__ = (isolate);                \
+    if (!(call).ToHandle(&__result__)) {             \
+      DCHECK(__isolate__->has_pending_exception());  \
+      return ReadOnlyRoots(__isolate__).exception(); \
+    }                                                \
+    DCHECK(!__isolate__->has_pending_exception());   \
+    return *__result__;                              \
+  } while (false)
+```
+上面这段代码最后的`RETURN_RESULT_OR_FAILURE`是宏模板，继续跟踪，进入`WriteDataValue()`,代码如下：  
+```c++
+void LookupIterator::WriteDataValue(Handle<Object> value,
+                                    bool initializing_store) {
+  DCHECK_EQ(DATA, state_);
+  Handle<JSReceiver> holder = GetHolder<JSReceiver>();
+  if (IsElement()) {
+    Handle<JSObject> object = Handle<JSObject>::cast(holder);
+    ElementsAccessor* accessor = object->GetElementsAccessor(isolate_);
+    accessor->Set(object, number_, *value);
+  } else if (holder->HasFastProperties(isolate_)) {
+    if (property_details_.location() == kField) {
+  //省略很多..............................    
+```
+`WriteDataValue()`方法先判断是不是全局对象，测试代码中字符串s定义在全局空间内，所以是全局变量，满足图1中标记位置的判断条件。    
+![avatar](f1.png)  
+注意看图1中的绿色标记，`value`的值是`hello world!`，它最终存以字典{key:value}形式存在全局表中,至此完成了s的定义。此时，它在V8中的类型是ONE_BYTE_INTERNALIZED_STRING，单字节字符串，这与书中的说法一致，s是字符串。  
+# 3 字符串的substring()方法  
+下面回答前述的问题2，如何转换。
+根据前面的源代码`var word = s.substring(s.indexOf(" ")+1,s.length);`,现在要执行`s.substring()`，在V8执行逻辑中，先要获取字符串s的substring()方法，也就是'.'操作。前述字节码中第14、15行把刚定义的字节串s存到了r2寄存器中，代码16行：  
+`LdaNamedPropertyNoFeedback r2, [3]`  
+这条字节码的作用是在r2寄存器（字符串变量s的地址）内容中获取常量池[3]（字符串substring）中的方法，就是获取s的`substring()`方法，字节码LdaNamedPropertyNoFeedback源码如下：  
+```c++
+1.  IGNITION_HANDLER(LdaNamedPropertyNoFeedback, InterpreterAssembler) {
+2.    TNode<Object> object = LoadRegisterAtOperandIndex(0);
+3.    TNode<Name> name = CAST(LoadConstantPoolEntryAtOperandIndex(1));
+4.    TNode<Context> context = GetContext();
+5.    TNode<Object> result =
+6.        CallBuiltin(Builtins::kGetProperty, context, object, name);
+7.    SetAccumulator(result);
+8.    CallRuntime(Runtime::kDebugPrint, context, object, name,result);//这里是我添加的调试命令
+9.    Dispatch();
+10.  }
+11.  //...........................分隔线..........................................
+12.  TF_BUILTIN(GetProperty, CodeStubAssembler) {
+13.    Node* object = Parameter(Descriptor::kObject);
+14.    Node* key = Parameter(Descriptor::kKey);
+15.    Node* context = Parameter(Descriptor::kContext);
+16.    // TODO(duongn): consider tailcalling to GetPropertyWithReceiver(object,
+17.    // object, key, OnNonExistent::kReturnUndefined).
+18.    Label if_notfound(this), if_proxy(this, Label::kDeferred),
+19.        if_slow(this, Label::kDeferred);
+20.    CodeStubAssembler::LookupInHolder lookup_property_in_holder =
+21.        [=](Node* receiver, Node* holder, Node* holder_map,
+22.            Node* holder_instance_type, Node* unique_name, Label* next_holder,
+23.            Label* if_bailout) {
+24.          VARIABLE(var_value, MachineRepresentation::kTagged);
+25.          Label if_found(this);
+26.          TryGetOwnProperty(context, receiver, holder, holder_map,
+27.                            holder_instance_type, unique_name, &if_found,
+28.                            &var_value, next_holder, if_bailout);
+29.          BIND(&if_found);
+30.          Return(var_value.value());
+31.        };
+32.    CodeStubAssembler::LookupInHolder lookup_element_in_holder =
+33.        [=](Node* receiver, Node* holder, Node* holder_map,
+34.            Node* holder_instance_type, Node* index, Label* next_holder,
+35.            Label* if_bailout) {
+36.          // Not supported yet.
+37.          Use(next_holder);
+38.          Goto(if_bailout);
+39.        };
+40.    TryPrototypeChainLookup(object, object, key, lookup_property_in_holder,
+41.                            lookup_element_in_holder, &if_notfound, &if_slow,
+42.                            &if_proxy);
+43.    BIND(&if_notfound);
+44.    Return(UndefinedConstant());
+45.    BIND(&if_slow);
+46.    TailCallRuntime(Runtime::kGetProperty, context, object, key);
+47.    BIND(&if_proxy);
+48.    {
+49.      // Convert the {key} to a Name first.
+50.      TNode<Object> name = CallBuiltin(Builtins::kToName, context, key);
+51.      // The {object} is a JSProxy instance, look up the {name} on it, passing
+52.      // {object} both as receiver and holder. If {name} is absent we can safely
+53.      // return undefined from here.
+54.      TailCallBuiltin(Builtins::kProxyGetProperty, context, object, name, object,
+55.                      SmiConstant(OnNonExistent::kReturnUndefined));
+56.    }
+57.  }
+```  
+调试过程中只有汇编码，无法看到C++源码，因为他们属于Builtin，是预先编译好并存储在`snapshot_blob.bin`文件中，V8启动时反序列化加载的二进制源码，关于Builtin详见之前的文章。  
+代码8行，是我加入的调用断点，触发时会进入C++源码环境，方便给大家展示程序状态。代码5行调用`TF_BUILTIN(GetProperty, CodeStubAssembler)`返回结果result，result是字符串`substring()`方法。  
+![avatar](f2.png)   
+图2是VS2019的调试窗口，前面提到无法做C++源码调试，在这看到的程序状态信息，因为代码8行是我添加的`CallRuntime(Runtime::kDebugPrint, context, object, name,result)`指令，才得以进入C++环境查看程序状态。这里只能看到程序状态，不要误以为这种方式可以摆脱汇编，一直在C++源码中调试执行，看图3调用堆栈。 
+![avatar](f3.png)   
+图3中可以看到，调用堆栈只有两层，因为`DebugPrint`由`Builtin::LdaNamedPropertyNoFeedback`调用，退出后还要回到汇编代码。  
+图2中的`args[0]`是'hello world!'，它是之前声明的全局变量s，注意看它的类型依旧就是ONE_BYTE_INTERNALIZED_STRING；再看`args[1]`是`substring`，是从常量池中读取的，它的类型同上；最后看`args[2]`,它的类型是JS_FUNCTION，这就是获取的`substring()`方法的地址指针，注意与`args[1]`的区别。  
+到此，转换过程完毕，我们并没有看到字符串s的类型在V8中发生过变化，但也没有阻碍获取字符串`substring()`方法。  
+# 4 技术总结
+**（1）** 相对于bool等几个基础类型，String是复合类型，本文只讲了一种字符串ONE_BYTE类型，下面给出其它字符串类型。  
+```c++
+switch (map.instance_type()) {
+    case CONS_STRING_TYPE:
+    case CONS_ONE_BYTE_STRING_TYPE:
+    case THIN_STRING_TYPE:
+    case THIN_ONE_BYTE_STRING_TYPE:
+    case SLICED_STRING_TYPE:
+    case SLICED_ONE_BYTE_STRING_TYPE:
+    case EXTERNAL_STRING_TYPE:
+    case EXTERNAL_ONE_BYTE_STRING_TYPE:
+    case UNCACHED_EXTERNAL_STRING_TYPE:
+    case UNCACHED_EXTERNAL_ONE_BYTE_STRING_TYPE:
+    case STRING_TYPE:
+    case ONE_BYTE_STRING_TYPE:
+    //省略............................
+```  
+在V8内部，对String类型做了进一步的详细区分，定义很多不同的字符串类型，上述代码每一个`XXX_STRING_TYPE`代表一种字符串类型。  
+**（2）** 全局字符串s的类型没有因为'.'操作发生变化。这绝对没违背书中所描述的技术原理，只是V8的具体实现方式不同而已。  
+**（3）** 从V8源码的角度来讲来，String类的父类是Name，Name的父类是HeapObject，最后是Ojbect类，这么说来，String类本身就是一个堆对象方法。但这和书中说的不是一个概念，书中强调:对字符串进行‘.’操作时，它就不再是字符串，而是一个对象了，注意区别。  
+**（4）** 下面是我用的`DebugPrint()`方法，这是V8内置方法，代码如下。
+```c++
+1.  RUNTIME_FUNCTION(Runtime_DebugPrint) {
+2.    SealHandleScope shs(isolate);
+3.    //DCHECK_EQ(1, args.length());这行我注释掉了
+4.    MaybeObject maybe_object(*args.address_of_arg_at(0));
+5.    StdoutStream os;
+6.    if (maybe_object->IsCleared()) {
+7.      os << "[weak cleared]";
+8.    } else {
+9.      Object object = maybe_object.GetHeapObjectOrSmi();
+10.      bool weak = maybe_object.IsWeak();
+11.  #ifdef DEBUG
+12.      if (object.IsString() && !isolate->context().is_null()) {
+13.        DCHECK(!weak);
+14.        // If we have a string, assume it's a code "marker"
+15.        // and print some interesting cpu debugging info.
+16.        object.Print(os);
+17.        JavaScriptFrameIterator it(isolate);
+18.        JavaScriptFrame* frame = it.frame();
+19.        os << "fp = " << reinterpret_cast<void*>(frame->fp())
+20.           << ", sp = " << reinterpret_cast<void*>(frame->sp())
+21.           << ", caller_sp = " << reinterpret_cast<void*>(frame->caller_sp())
+22.           << ": ";
+23.      } else {
+24.        os << "DebugPrint: ";
+25.        if (weak) {
+26.          os << "[weak] ";
+27.        }
+28.        object.Print(os);
+29.      }
+30.      if (object.IsHeapObject()) {
+31.        HeapObject::cast(object).map().Print(os);
+32.      }
+33.  #else
+34.      if (weak) {
+35.        os << "[weak] ";
+36.      }
+37.      // ShortPrint is available in release mode. Print is not.
+38.      os << Brief(object);
+39.  #endif
+40.    }
+41.    os << std::endl;
+42.    return args[0];  // return TOS
+43.  }
+```  
+该方法类似“断点”功能，在调试V8源码时，可以在Builtin中使用，并把想要观察的变量作为参数传入，就可以回到C++环境查看程序状态。  
+这个方法原本是为调试Javascript源码提供的，在JS中的使用方式是`%DebugPrint()`。我用来充当调试断点，给大家展示程序中断状态。在Builtin中的调用方法是：`CallRuntime(Runtime::kDebugPrint, context, your args0,your args1....);`。    
+好了，今天到这里，下次见。   
+
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap13-1020/f1.png b/chap13-1020/f1.png
new file mode 100644
index 0000000..c1a946a
Binary files /dev/null and b/chap13-1020/f1.png differ
diff --git a/chap13-1020/f2.png b/chap13-1020/f2.png
new file mode 100644
index 0000000..b72d37a
Binary files /dev/null and b/chap13-1020/f2.png differ
diff --git a/chap13-1020/f3.png b/chap13-1020/f3.png
new file mode 100644
index 0000000..ff45880
Binary files /dev/null and b/chap13-1020/f3.png differ
diff --git a/chap14-1019/README.md b/chap14-1019/README.md
new file mode 100644
index 0000000..6a8bebb
--- /dev/null
+++ b/chap14-1019/README.md
@@ -0,0 +1,343 @@
+# 《Chrome V8原理讲解》第14篇 看V8如何表示JS的动态类型
+![avatar](../v8.png)  
+# 1 摘要  
+JavaScript是动态类型语言，数据类型具有不确定性。V8是用C++编写的，C++是强类型语言，要求类型确定。类型确定的C++是如何表达类型不确定的JS呢？解决方法是：操作JS数据前先查询类型，再操作。这又产生了新问题--性能损耗，因为类型查询是极为耗时的操作，频繁使用严重影响程序运行速度。为此，V8采用了Map机制，也称为隐藏类（Hidden Class）。**注意：** Map机制与JS中的`map()`没有关系，只是同名。Map机制可以很好地表达JS的不确定性，它的主要作用是降低性能损耗。本文通过形象化的比喻和深入的源码分析，使大家从宏观和微观角度全面累计Map机制，本文组织结构：Map原理，它如何表达Javascript的动态类型（章节2）；V8初始化阶段对Map的处理过程（章节3）。 
+# 2 Map原理  
+由于Javascript类型的不确定性，V8操作Javascript对象（例如：调用方法、访问对对象成员）前要先查询其类型。因此，V8引入了Map机制，它是一种用于描述类型的数据结构，可以形象地把它叫作“地图”，它的使用特点是固定的位置存储指定的内容，如图1所示。    
+![avatar](f1.png)  
+借助图1，我们对Map机制进行概要描述：  
+**（1）** JS开发者角度，仅能看到存储空间，这段存储空间保存了开发者定义的JS对象，但V8不知道对象类型；  
+**（2）** 指针，它是存储空间的第一个位置，类型是指针，大小8byte（64位系统中），这个指针由V8维护，开发者看不到，所以叫隐藏类。它的作用是指向Map；  
+**（3）** V8角度，能看到指针+存储空间，就可以找到Map。这个Map大小是固定的80byte，存储信息的格式与位置也是固定的，存储信息包括：JS对象的存储空间有哪些成员，成员类型，成员偏移地址等。所以说，Map就是地图。  
+V8通过查询Map，可以知道存储空间内存放了什么，怎么存放的，进而正确操作JS对象。一句话总结：V8利用类型确定的Map类（c++实现的class对象）管理JS的动态类型。其实，在V8角度看，Map类型是确定的，所以整体数据类型就是确定的。最重要是Map提高了效率，因为它代替了耗时的JS对象类型检索操作。
+下面来看Map的布局：     
+```c++
+1.  Map layout:
+2.  // +---------------+---------------------------------------------+
+3.  // |   _ Type _    | _ Description _                             |
+4.  // +---------------+---------------------------------------------+
+5.  // | TaggedPointer | map - Always a pointer to the MetaMap root  |
+6.  // +---------------+---------------------------------------------+
+7.  // | Int           | The first int field                         |
+8.  //  `---+----------+---------------------------------------------+
+9.  //      | Byte     | [instance_size]                             |
+10.  //      +----------+---------------------------------------------+
+11.  //      | Byte     | If Map for a primitive type:                |
+12.  //      |          |   native context index for constructor fn   |
+13.  //      |          | If Map for an Object type:                  |
+14.  //      |          |   inobject properties start offset in words |
+15.  //      +----------+---------------------------------------------+
+16.  //      | Byte     | [used_or_unused_instance_size_in_words]     |
+17.  //      |          | For JSObject in fast mode this byte encodes |
+18.  //      |          | the size of the object that includes only   |
+19.  //      |          | the used property fields or the slack size  |
+20.  //      |          | in properties backing store.                |
+21.  //      +----------+---------------------------------------------+
+22.  //      | Byte     | [visitor_id]                                |
+23.  // +----+----------+---------------------------------------------+
+24.  // | Int           | The second int field                        |
+25.  //  `---+----------+---------------------------------------------+
+26.  //      | Short    | [instance_type]                             |
+27.  //      +----------+---------------------------------------------+
+28.  //      | Byte     | [bit_field]                                 |
+29.  //      |          |   - has_non_instance_prototype (bit 0)      |
+30.  //      |          |   - is_callable (bit 1)                     |
+31.  //      |          |   - has_named_interceptor (bit 2)           |
+32.  //      |          |   - has_indexed_interceptor (bit 3)         |
+33.  //      |          |   - is_undetectable (bit 4)                 |
+34.  //      |          |   - is_access_check_needed (bit 5)          |
+35.  //      |          |   - is_constructor (bit 6)                  |
+36.  //      |          |   - has_prototype_slot (bit 7)              |
+37.  //      +----------+---------------------------------------------+
+38.  //      | Byte     | [bit_field2]                                |
+39.  //      |          |   - new_target_is_base (bit 0)              |
+40.  //      |          |   - is_immutable_proto (bit 1)              |
+41.  //      |          |   - unused bit (bit 2)                      |
+42.  //      |          |   - elements_kind (bits 3..7)               |
+43.  // +----+----------+---------------------------------------------+
+44.  // | Int           | [bit_field3]                                |
+45.  // |               |   - enum_length (bit 0..9)                  |
+46.  // |               |   - number_of_own_descriptors (bit 10..19)  |
+47.  // |               |   - is_prototype_map (bit 20)               |
+48.  // |               |   - is_dictionary_map (bit 21)              |
+49.  // |               |   - owns_descriptors (bit 22)               |
+50.  // |               |   - is_in_retained_map_list (bit 23)        |
+51.  // |               |   - is_deprecated (bit 24)                  |
+52.  // |               |   - is_unstable (bit 25)                    |
+53.  // |               |   - is_migration_target (bit 26)            |
+54.  // |               |   - is_extensible (bit 28)                  |
+55.  // |               |   - may_have_interesting_symbols (bit 28)   |
+56.  // |               |   - construction_counter (bit 29..31)       |
+57.  // |               |                                             |
+58.  // +*************************************************************+
+59.  // | Int           | On systems with 64bit pointer types, there  |
+60.  // |               | is an unused 32bits after bit_field3        |
+61.  // +*************************************************************+
+62.  // | TaggedPointer | [prototype]                                 |
+63.  // +---------------+---------------------------------------------+
+64.  // | TaggedPointer | [constructor_or_backpointer]                |
+65.  // +---------------+---------------------------------------------+
+66.  // | TaggedPointer | [instance_descriptors]                      |
+67.  // +*************************************************************+
+68.  // ! TaggedPointer ! [layout_descriptors]                        !
+69.  // !               ! Field is only present if compile-time flag  !
+70.  // !               ! FLAG_unbox_double_fields is enabled         !
+71.  // !               ! (basically on 64 bit architectures)         !
+72.  // +*************************************************************+
+73.  // | TaggedPointer | [dependent_code]                            |
+74.  // +---------------+---------------------------------------------+
+75.  // | TaggedPointer | [prototype_validity_cell]                   |
+76.  // +---------------+---------------------------------------------+
+77.  // | TaggedPointer | If Map is a prototype map:                  |
+78.  // |               |   [prototype_info]                          |
+79.  // |               | Else:                                       |
+80.  // |               |   [raw_transitions]                         |
+81.  // +---------------+---------------------------------------------+
+```   
+前面提到Map是格式统一、大小固定的数据结构，即规定的位置代表指定的含义。上面代码是它的格式，它大小是80个字节，代码9行，instance_size代表图1中的存储空间的大小；代码24行，instance_type代表图1中的存储空间内的JS数据类型，例如：JS数组、JSFunction等。代码66行，instance_descriptors对JS数据的详细描述，例如：每个成员都是什么，存在哪里等。
+**注意**：每一个JavaScript对象的存储空间的第一个位置都是一个Map指针，也就是每个js对象都有Map，Map大小不因js对象不同而改变，始终是80字节，存储内容也如上所示，保持不变。它用来描述JS对象的形状，相同形状的不同js对象共同一个Map。“形状相同”是类型一样，内部成员存储布局也一样，如下面代码：
+```c++
+function Point(x,y) {
+	this.x = x;
+	this.y = y;
+}
+
+var fun1 = new Point(1,2);
+var fun2 = new Point(3,4);
+```  
+`fun1`和`fun2`共用一个Map，因为他们的形状一样。执行`fun2.z=80;`之后，fun2的形状发生了变，随之会有新的Map产生，叫Map迁移，后续文章会讲解。
+下面来看是Map类的核心代码：  
+```c++
+1.  class Map : public HeapObject {
+2.   public:
+3.  //...............省略很多..................
+4.     DECL_PRIMITIVE_ACCESSORS(bit_field, byte)
+5.     DECL_PRIMITIVE_ACCESSORS(relaxed_bit_field, byte)
+6.   // Bit positions for |bit_field|.
+7.   #define MAP_BIT_FIELD_FIELDS(V, _)          \
+8.     V(HasNonInstancePrototypeBit, bool, 1, _) \
+9.     V(IsCallableBit, bool, 1, _)              \
+10.     V(HasNamedInterceptorBit, bool, 1, _)     \
+11.     V(HasIndexedInterceptorBit, bool, 1, _)   \
+12.     V(IsUndetectableBit, bool, 1, _)          \
+13.     V(IsAccessCheckNeededBit, bool, 1, _)     \
+14.     V(IsConstructorBit, bool, 1, _)           \
+15.     V(HasPrototypeSlotBit, bool, 1, _)
+16.     DEFINE_BIT_FIELDS(MAP_BIT_FIELD_FIELDS)
+17.   #undef MAP_BIT_FIELD_FIELDS
+18.     // Bit field 2.
+19.     DECL_PRIMITIVE_ACCESSORS(bit_field2, byte)
+20.   // Bit positions for |bit_field2|.
+21.   #define MAP_BIT_FIELD2_FIELDS(V, _)      \
+22.     V(NewTargetIsBaseBit, bool, 1, _)      \
+23.     V(IsImmutablePrototypeBit, bool, 1, _) \
+24.     V(UnusedBit, bool, 1, _)               \
+25.     V(ElementsKindBits, ElementsKind, 5, _)
+26.     DEFINE_BIT_FIELDS(MAP_BIT_FIELD2_FIELDS)
+27.   #undef MAP_BIT_FIELD2_FIELDS
+28.     DECL_PRIMITIVE_ACCESSORS(bit_field3, uint32_t)
+29.     V8_INLINE void clear_padding();
+30.   // Bit positions for |bit_field3|.
+31.   #define MAP_BIT_FIELD3_FIELDS(V, _)                               \
+32.     V(EnumLengthBits, int, kDescriptorIndexBitCount, _)             \
+33.     V(NumberOfOwnDescriptorsBits, int, kDescriptorIndexBitCount, _) \
+34.     V(IsPrototypeMapBit, bool, 1, _)                                \
+35.     V(IsDictionaryMapBit, bool, 1, _)                               \
+36.     V(OwnsDescriptorsBit, bool, 1, _)                               \
+37.     V(IsInRetainedMapListBit, bool, 1, _)                           \
+38.     V(IsDeprecatedBit, bool, 1, _)                                  \
+39.     V(IsUnstableBit, bool, 1, _)                                    \
+40.     V(IsMigrationTargetBit, bool, 1, _)                             \
+41.     V(IsExtensibleBit, bool, 1, _)                                  \
+42.     V(MayHaveInterestingSymbolsBit, bool, 1, _)                     \
+43.     V(ConstructionCounterBits, int, 3, _)
+44.     DEFINE_BIT_FIELDS(MAP_BIT_FIELD3_FIELDS)
+45.   #undef MAP_BIT_FIELD3_FIELDS
+46.      DEFINE_FIELD_OFFSET_CONSTANTS(HeapObject::kHeaderSize,
+47.                                    TORQUE_GENERATED_MAP_FIELDS)
+48.      //...............省略很多..................
+49.      OBJECT_CONSTRUCTORS(Map, HeapObject);
+50.  };
+```  
+上述代码中，只保留了MAP格式的定义，我们对DEFINE_FIELD_OFFSET_CONSTANTS做展开，如下：  
+```c++
+1.    enum {
+2.  TORQUE_GENERATED_MAP_FIELDS_StartOffset= 7,
+3.  kInstanceSizeInWordsOffset=8, kInstanceSizeInWordsOffsetEnd = 8,
+4.  kInObjectPropertiesStartOrConstructorFunctionIndexOffset=9, kInObjectPropertiesStartOrConstructorFunctionIndexOffsetEnd = 9,
+5.  kUsedOrUnusedInstanceSizeInWordsOffset=10, kUsedOrUnusedInstanceSizeInWordsOffsetEnd = 10,
+6.  kVisitorIdOffset=11, kVisitorIdOffsetEnd = 11,
+7.  kInstanceTypeOffset=12, kInstanceTypeOffsetEnd = 13,
+8.  kBitFieldOffset=14, kBitFieldOffsetEnd = 14,
+9.  kBitField2Offset=15, kBitField2OffsetEnd = 15,
+10.  kBitField3Offset=16, kBitField3OffsetEnd = 19,
+11.  kOptionalPaddingOffset=20, kOptionalPaddingOffsetEnd = 23,
+12.  kStartOfStrongFieldsOffset=24, kStartOfStrongFieldsOffsetEnd = 23,
+13.  kPrototypeOffset=24, kPrototypeOffsetEnd = 31,
+14.  kConstructorOrBackPointerOffset=32, kConstructorOrBackPointerOffsetEnd = 39,
+15.  kInstanceDescriptorsOffset=40, kInstanceDescriptorsOffsetEnd = 47,
+16.  kLayoutDescriptorOffset=48, kLayoutDescriptorOffsetEnd = 55,
+17.  kDependentCodeOffset=56, kDependentCodeOffsetEnd = 63,
+18.  kPrototypeValidityCellOffset=64, kPrototypeValidityCellOffsetEnd = 71,
+19.  kEndOfStrongFieldsOffset=72, kEndOfStrongFieldsOffsetEnd = 71,
+20.  kStartOfWeakFieldsOffset=72, kStartOfWeakFieldsOffsetEnd = 71,
+21.  kTransitionsOrPrototypeInfoOffset=72, kTransitionsOrPrototypeInfoOffsetEnd = 79,
+22.  kEndOfWeakFieldsOffset=80, kEndOfWeakFieldsOffsetEnd = 79,
+23.  kSize=80, kSizeEnd = 79,
+24.    }
+```  
+代码2行TORQUE_GENERATED_MAP_FIELDS_StartOffset说明了Map的起始偏移是7（从0算起），也就是第8个字节，前面提到一个Map的大小是80个字节，由于Map继承Heap对象，这80个字节中的前8个字节是Heap对象，所以它的实际可用的字节是72个，每个成员的偏移和大小与前述第一段代码（Map Layout）对应。Map的创建和回收由V8的Heap负责管理，下面是创建Map的源码位置：  
+```c++
+1.  AllocationResult Heap::AllocateRaw(int size_in_bytes, AllocationType type,
+2.                                     AllocationOrigin origin,
+3.                                     AllocationAlignment alignment) {
+4.  //.....省略很多.......
+5.    if (AllocationType::kYoung == type) {
+6.  //.....省略很多.......
+7.    } else if (AllocationType::kOld == type) {
+8.  //.....省略很多.......
+9.    } else if (AllocationType::kCode == type) {
+10.      if (size_in_bytes <= code_space()->AreaSize() && !large_object) {
+11.        allocation = code_space_->AllocateRawUnaligned(size_in_bytes);
+12.      } else {
+13.        allocation = code_lo_space_->AllocateRaw(size_in_bytes);
+14.      }
+15.    } else if (AllocationType::kMap == type) {
+16.      allocation = map_space_->AllocateRawUnaligned(size_in_bytes);
+17.    } else if (AllocationType::kReadOnly == type) {
+18.  #ifdef V8_USE_SNAPSHOT
+19.      DCHECK(isolate_->serializer_enabled());
+20.  #endif
+21.      DCHECK(!large_object);
+22.      DCHECK(CanAllocateInReadOnlySpace());
+23.      DCHECK_EQ(AllocationOrigin::kRuntime, origin);
+24.      allocation =
+25.          read_only_space_->AllocateRaw(size_in_bytes, alignment, origin);
+26.    } else {
+27.      UNREACHABLE();
+28.    }
+29.    return allocation;
+30.  }
+```  
+代码15行，`type=KMap`时`size_in_bytes`是80，进入代码16行分配内存，图2给出了执行代码16的调用堆栈。  
+![avatar](f2.png)  
+`AllocateRaw()`分配内存后返回到`AllocateMap()`,对内存进行初始化，代码如下：  
+```c++
+1.  Map Factory::InitializeMap(Map map, InstanceType type, int instance_size,
+2.                             ElementsKind elements_kind,
+3.                             int inobject_properties) {
+4.    map.set_instance_type(type);
+5.    map.set_prototype(*null_value(), SKIP_WRITE_BARRIER);
+6.    map.set_constructor_or_backpointer(*null_value(), SKIP_WRITE_BARRIER);
+7.    map.set_instance_size(instance_size);
+8.    if (map.IsJSObjectMap()) {
+9.      DCHECK(!ReadOnlyHeap::Contains(map));
+10.      map.SetInObjectPropertiesStartInWords(instance_size / kTaggedSize -
+11.                                            inobject_properties);
+12.      DCHECK_EQ(map.GetInObjectProperties(), inobject_properties);
+13.      map.set_prototype_validity_cell(*invalid_prototype_validity_cell());
+14.    } else {
+15.      DCHECK_EQ(inobject_properties, 0);
+16.      map.set_inobject_properties_start_or_constructor_function_index(0);
+17.      map.set_prototype_validity_cell(Smi::FromInt(Map::kPrototypeChainValid));
+18.    }
+19.    map.set_dependent_code(DependentCode::cast(*empty_weak_fixed_array()),
+20.                           SKIP_WRITE_BARRIER);
+21.    map.set_raw_transitions(MaybeObject::FromSmi(Smi::zero()));
+22.    map.SetInObjectUnusedPropertyFields(inobject_properties);
+23.    map.SetInstanceDescriptors(isolate(), *empty_descriptor_array(), 0);
+24.    if (FLAG_unbox_double_fields) {
+25.      map.set_layout_descriptor(LayoutDescriptor::FastPointerLayout());
+26.    }
+27.  //.................省略很多...............
+28.    return map;
+29.  }
+```  
+上面代码是对Map的初始化，按最开始给出的May layout对每个字段（bit位、byte位、short位等）进行初始化。代码8，9，10，13行对JSObject对象中的InObject数据进行初始化，“InObject”是存储在JSObject对象内部的数据，访问这些数据更快。代码28返回Map,至此Map生成完毕，后续会通过这个Map访问图1中的存储空间，请读者自行跟踪代码，不再赘述。  
+# 3 Map初始化  
+在V8的启动阶段，`CreateInitialMaps()`对所有Javascript类型分别建立对应的空Map，“空Map”说明了创建某个JS类型数据所需的最小内存空间。这样，开发者创建javascript对象时，V8先用对应的空Map申请一段最小空间，随时开发者对JS对象添加成员，Map也会发生改变。下面给出Map初始化的源码：  
+```c++
+1.  bool Heap::CreateInitialMaps() {//....代码太长，中间省略很多........
+2.    HeapObject obj;
+3.    {
+4.      AllocationResult allocation = AllocatePartialMap(MAP_TYPE, Map::kSize);
+5.      if (!allocation.To(&obj)) return false;
+6.    }
+7.    Map new_meta_map = Map::unchecked_cast(obj);
+8.    set_meta_map(new_meta_map);
+9.    new_meta_map.set_map_after_allocation(new_meta_map);
+10.  //...................分隔线....................
+11.    ReadOnlyRoots roots(this);
+12.    {  // Partial map allocation
+13.  #define ALLOCATE_PARTIAL_MAP(instance_type, size, field_name)                \
+14.    {                                                                          \
+15.      Map map;                                                                 \
+16.      if (!AllocatePartialMap((instance_type), (size)).To(&map)) return false; \
+17.      set_##field_name##_map(map);                                             \
+18.    }
+19.      ALLOCATE_PARTIAL_MAP(FIXED_ARRAY_TYPE, kVariableSizeSentinel, fixed_array);
+20.      ALLOCATE_PARTIAL_MAP(WEAK_FIXED_ARRAY_TYPE, kVariableSizeSentinel,
+21.                           weak_fixed_array);
+22.      ALLOCATE_PARTIAL_MAP(WEAK_ARRAY_LIST_TYPE, kVariableSizeSentinel,
+23.  //...................分隔线....................
+24.  #undef ALLOCATE_PARTIAL_MAP
+25.    }
+26.    // Allocate the empty array.
+27.    {
+28.      AllocationResult alloc =
+29.          AllocateRaw(FixedArray::SizeFor(0), AllocationType::kReadOnly);
+30.      if (!alloc.To(&obj)) return false;
+31.      obj.set_map_after_allocation(roots.fixed_array_map(), SKIP_WRITE_BARRIER);
+32.      FixedArray::cast(obj).set_length(0);
+33.    }
+34.    set_empty_fixed_array(FixedArray::cast(obj));
+35.  //...................分隔线....................
+36.    FinalizePartialMap(roots.meta_map());
+37.    FinalizePartialMap(roots.fixed_array_map());
+38.    FinalizePartialMap(roots.weak_fixed_array_map());
+39.    {
+40.      if (!AllocateRaw(FixedArray::SizeFor(0), AllocationType::kReadOnly)
+41.               .To(&obj)) {
+42.        return false;
+43.      }
+44.      obj.set_map_after_allocation(roots.closure_feedback_cell_array_map(),
+45.                                   SKIP_WRITE_BARRIER);
+46.      FixedArray::cast(obj).set_length(0);
+47.      set_empty_closure_feedback_cell_array(ClosureFeedbackCellArray::cast(obj));
+48.    }
+49.    DCHECK(!InYoungGeneration(roots.empty_fixed_array()));
+50.    roots.bigint_map().SetConstructorFunctionIndex(
+51.        Context::BIGINT_FUNCTION_INDEX);
+52.    return true;
+53.  }
+```  
+分隔线把代码分成了四部分，代码4,5,6,7,8行创建`meta_data`，这是所有Map都要用的元信息；代码13~22行，结合宏模板`ALLOCATE_PARTIAL_MAP`创建`ARRAY`和`ARRAY_LIST`类型的Map；代码27~34行创建其类型Map；分三批创建是因为后者的创建要依赖前者。最后，36开始，是完成所有Map创建的最终工作，并存储到root_table中，图3给出部分Map在root_table中的存储位置。  
+![avatar](f3.png)  
+root_table是由下面的一系列宏板定义实现的指针类型数组，通过debug跟踪代码，可以看到meta_data在root_table中的位置下标是10，其它的下标请读者自行计算。
+```c++
+#define READ_ONLY_ROOT_LIST(V)     \
+  STRONG_READ_ONLY_ROOT_LIST(V)    \
+  INTERNALIZED_STRING_ROOT_LIST(V) \
+  PRIVATE_SYMBOL_ROOT_LIST(V)      \
+  PUBLIC_SYMBOL_ROOT_LIST(V)       \
+  WELL_KNOWN_SYMBOL_ROOT_LIST(V)   \
+  STRUCT_MAPS_LIST(V)              \
+  ALLOCATION_SITE_MAPS_LIST(V)     \
+  DATA_HANDLER_MAPS_LIST(V)
+
+#define MUTABLE_ROOT_LIST(V)                \
+  STRONG_MUTABLE_IMMOVABLE_ROOT_LIST(V)     \
+  STRONG_MUTABLE_MOVABLE_ROOT_LIST(V)       \
+  V(StringTable, string_table, StringTable) \
+  SMI_ROOT_LIST(V)
+
+#define ROOT_LIST(V)     \
+  READ_ONLY_ROOT_LIST(V) \
+  MUTABLE_ROOT_LIST(V)
+```   
+上述定义了root_table,通过宏模板的参数，可猜想出每个元素的大体功能和作用，配合debug跟踪来验证猜想是否确。  
+  
+好了，今天到这里，下次见。   
+
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap14-1019/f1.png b/chap14-1019/f1.png
new file mode 100644
index 0000000..6007cf5
Binary files /dev/null and b/chap14-1019/f1.png differ
diff --git a/chap14-1019/f2.png b/chap14-1019/f2.png
new file mode 100644
index 0000000..fb78f97
Binary files /dev/null and b/chap14-1019/f2.png differ
diff --git a/chap14-1019/f3.png b/chap14-1019/f3.png
new file mode 100644
index 0000000..c0f4047
Binary files /dev/null and b/chap14-1019/f3.png differ
diff --git a/chap15-1024/README.md b/chap15-1024/README.md
new file mode 100644
index 0000000..42690a6
--- /dev/null
+++ b/chap15-1024/README.md
@@ -0,0 +1,269 @@
+# 《Chrome V8原理讲解》第十五篇 运行时辅助类，给V8添加钩子函数
+  
+![avatar](../v8.png)  
+# 前言  
+本系列的前十三篇文，讲解了V8执行Javascript时最基础的工作流程和原理，包括词法分析、语法分析、字节码生成、Builtins方法、ignition执行单元，等等，达到了从零做起，入门学习的目的。  
+接下来的文章将以问题为导向讲解V8源码，例如：以闭包技术、或垃圾加收（GC）为专题讲解V8中的相关源码。V8代码过于庞大，以问题为导向可以使得学习主题更加明确、效果更好。同时，我争取做到每篇文章是一个独立的知识点，方便大家阅读。  
+读者可以把想学的内容在文末评论区留言，我汇总后出专题文章。  
+# 1 摘要  
+Javascript的部分功能，如属性访问，新建对象、正则表达式等，由C++编码、以独立函数的形式存在，JavaScript在运行时以函数调用方式使用这些功能，所以称之为Runtime辅助类。`new ojbect()`、`prototype`等功能均由C++函数实现，由于V8封装了这些函数，所以Javascript开发者看不到使用细节。本文讲解Runtime的使用细节，内容包括以下三方面：  
+**（1）** Runtime源码讲解，数据结构和定义方法；  
+**（2）** 调用约定，Bytecode如何调用Runtime功能，即builtin调用Runtime功能的约定；  
+**（3）** 自定义Runtime功能方法，随时随地给V8添加钩子函数。  
+# 2 Runtime源码  
+先说明runtime功能有哪些？叫什么？功能是什么？答案在runtime.h文件中，源码如下：
+```c++
+1.  #define FOR_EACH_INTRINSIC_GENERATOR(F, I)    \
+2.    I(AsyncFunctionAwaitCaught, 2, 1)           \
+3.    I(AsyncFunctionAwaitUncaught, 2, 1)         \
+4.    I(AsyncFunctionEnter, 2, 1)                 \
+5.    I(AsyncFunctionReject, 3, 1)                \
+6.    I(AsyncFunctionResolve, 3, 1)               \
+7.    I(AsyncGeneratorAwaitCaught, 2, 1)          \
+8.    I(GeneratorGetResumeMode, 1, 1)
+9.  #define FOR_EACH_INTRINSIC_MODULE(F, I) \ //省略很多.....................
+10.    F(DynamicImportCall, 2, 1)            \
+11.    I(GetImportMetaObject, 0, 1)          \
+12.    F(GetModuleNamespace, 1, 1)
+13.  #define FOR_EACH_INTRINSIC_NUMBERS(F, I) \
+14.    F(GetHoleNaNLower, 0, 1)               \
+15.    F(GetHoleNaNUpper, 0, 1)               \
+16.    I(IsSmi, 1, 1)                         \
+17.    F(IsValidSmi, 1, 1)                    \
+18.    F(MaxSmi, 0, 1)                        \
+19.    F(NumberToString, 1, 1)                \
+20.    F(StringParseFloat, 1, 1)              \ //省略很多.....................
+21.    F(StringParseInt, 2, 1)                \
+22.    F(StringToNumber, 1, 1)
+23.  #define FOR_EACH_INTRINSIC_OBJECT(F, I)                         \
+24.    F(AddDictionaryProperty, 3, 1)                                \
+25.    F(NewObject, 2, 1)  
+26.  #define FOR_EACH_INTRINSIC_REGEXP(F, I)             \
+27.    I(IsRegExp, 1, 1)                                 \
+28.    F(RegExpExec, 4, 1)                               \
+29.    F(RegExpExecMultiple, 4, 1)                       \
+30.    F(RegExpInitializeAndCompile, 3, 1)               \
+31.    F(RegExpReplaceRT, 3, 1)                          \
+32.    F(RegExpSplit, 3, 1)                              \
+33.    F(StringReplaceNonGlobalRegExpWithFunction, 3, 1) \
+34.    F(StringSplit, 3, 1)
+35.  #define FOR_EACH_INTRINSIC_STRINGS(F, I)  \
+36.    F(StringGreaterThan, 2, 1)              \
+37.    F(StringGreaterThanOrEqual, 2, 1)       \
+38.    F(StringIncludes, 3, 1)                 \
+39.    F(StringIndexOf, 3, 1)                  \
+40.    F(StringIndexOfUnchecked, 3, 1)         \
+41.    F(StringLastIndexOf, 2, 1)              \
+42.    F(StringLessThan, 2, 1)                 \
+43.    F(StringLessThanOrEqual, 2, 1)          \
+44.    F(StringMaxLength, 0, 1)                \
+45.    F(StringReplaceOneCharWithString, 3, 1) \
+46.    F(StringCompareSequence, 3, 1)          \
+47.    F(StringSubstring, 3, 1)                \
+48.    F(StringToArray, 2, 1)                  \
+49.    F(StringTrim, 2, 1)
+```  
+上述代码是Runtime定义使用的宏模板，省略了很多，保留了一些常见的、有代表性的功能。每一行代表一个功能函数，以`F(NewObject, 2, 1)`说明定义格式：  
+`F`，最终会被替换成另一个宏，宏里嵌套另一个宏，另外以`I`开头的，也是一样，使用`F`和`I`（IntrinsicTypes）是为方便代码重用，这是V8代码的书写风格；  
+`NewObject`是函数名，实现Javascript中的对象创建功能；  
+`2,1`，其中`2`是参数的数量，`1`是返回值的数量。  
+代码2~7行的`AsyncXXX`功能对应的是Javascript中的异步功能；代码19~22行，类型转换；代码25行，新建对象；代码27~32行，正则表达式；代码36行~最后，各种字符串的操作。  
+上述代码只给出了函数名和参数说明，并没有定义，下面给出`NewObject`的源码如下：  
+```c++
+RUNTIME_FUNCTION(Runtime_NewObject) {
+  HandleScope scope(isolate);
+  DCHECK_EQ(2, args.length());
+  CONVERT_ARG_HANDLE_CHECKED(JSFunction, target, 0);
+  CONVERT_ARG_HANDLE_CHECKED(JSReceiver, new_target, 1);
+  RETURN_RESULT_OR_FAILURE(
+      isolate,
+      JSObject::New(target, new_target, Handle<AllocationSite>::null()));
+}
+```  
+在V8查询相关源码的方法是：通过“Runtime_+函数名”的方式，在V8\src文件夹中检索，大部分都在`v8\src\runtime\`中。代码中`RUNTIME_FUNCTION`是一个宏模板，我们将其展开，并与`NewObject`组成完成的函数源码如下：    
+```C++
+1.  static V8_INLINE Object __RT_impl_Runtime_NewObject(Arguments args,              
+2.                                                 Isolate* isolate);           
+3.  V8_NOINLINE static Address Stats_Runtime_NewObject(int args_length, Address* args_object, 
+4.                                       Isolate* isolate) {                    
+5.    RuntimeCallTimerScope timer(isolate, RuntimeCallCounterId::kRuntime_NewObject);      
+6.    TRACE_EVENT0(TRACE_DISABLED_BY_DEFAULT("v8.runtime"),                     
+7.                 "V8.Runtime_" "Runtime_NewObject");                                        
+8.    Arguments args(args_length, args_object);                                 
+9.    return (__RT_impl_Runtime_NewObject(args, isolate)).ptr();                          
+10.   }                                                                           
+11.   Address Name(int args_length, Address* args_object, Isolate* isolate) {        
+12.     DCHECK(isolate->context().is_null() || isolate->context().IsContext());   
+13.     CLOBBER_DOUBLE_REGISTERS();                                               
+14.     if (V8_UNLIKELY(TracingFlags::is_runtime_stats_enabled())) {              
+15.       return Stats_Runtime_NewObject(args_length, args_object, isolate);                 
+16.     }                                                                         
+17.     Arguments args(args_length, args_object);                                 
+18.     return (__RT_impl_Runtime_NewObject(args, isolate)).ptr();                          
+19.   }                                                                          
+20.  //.................分隔线............... 
+21.   static Object __RT_impl_Runtime_NewObject(Arguments args, Isolate* isolate)
+22.  {
+23.    HandleScope scope(isolate);
+24.    DCHECK_EQ(2, args.length());
+25.    CONVERT_ARG_HANDLE_CHECKED(JSFunction, target, 0);
+26.    CONVERT_ARG_HANDLE_CHECKED(JSReceiver, new_target, 1);
+27.    RETURN_RESULT_OR_FAILURE(
+28.        isolate,
+29.        JSObject::New(target, new_target, Handle<AllocationSite>::null()));
+30.  }
+```
+上述代码中，分隔线以下是创建对象的入口函数，最终会调用`JSObject::New()`，这里完成创建对象。创建对象过程中会涉及到创建Map等知识点，内容较多，后续文章专题讲解，请读者先预习。
+# 3 Runtime调用约定，添加钩子函数  
+看懂了Runtime函数的构建方法，也就明白了V8对runtime的封装方式，更能理解Javascript中很多功能的实现原理。Runtime函数的构建方法总结为以下两点：  
+**（1）** `Runtime`类中有一个枚举成员，成员是函数名。
+```c++
+class Runtime : public AllStatic {
+ public:
+  enum FunctionId : int32_t {
+#define F(name, nargs, ressize) k##name,
+#define I(name, nargs, ressize) kInline##name,
+    FOR_EACH_INTRINSIC(F) FOR_EACH_INLINE_INTRINSIC(I)
+#undef I
+#undef F
+        kNumFunctions,
+  };
+//省略很多.......................
+```
+配合上面的宏模板，展开后是一个`FunctionId`成员。  
+**（2）** V8在编译阶段生成一个runtime函数指针数组（runtime_table），数组下标是枚举成员，数组成员（指针）指针对应的函数地址，最终runtime_table存储在isolate中。  
+这两点内容需要详细看代码分析，需要慢慢理解。**我们绕过这些讨厌的原理！给出最直接的方法，按此操作就可以添加自定义功能！** 随便找个宏定义的位置，例如下面的代码，最后一行是我添加的自定义功能。  
+```c++
+#define FOR_EACH_INTRINSIC_TEST(F, I)         \
+  F(Abort, 1, 1)                              \
+  F(AbortJS, 1, 1)                            \
+  F(AbortCSAAssert, 1, 1)                     \
+  F(ArraySpeciesProtector, 0, 1)              \
+  F(ClearFunctionFeedback, 1, 1)              \
+  F(ClearMegamorphicStubCache, 0, 1)          \
+  F(CloneWasmModule, 1, 1)                    \
+  F(CompleteInobjectSlackTracking, 1, 1)      \
+  F(ConstructConsString, 2, 1)                \
+  F(ConstructDouble, 2, 1)                    \
+  F(ConstructSlicedString, 2, 1)              \
+  F(MyRuntime,1,1)                            //这是我新加入的
+```
+最后一行，名字是`MyRuntime`，一个参数和一个返回值，再随便找个位置写函数定义，我写在了runtime-test.cc中，代码如下：  
+```c++
+1.RUNTIME_FUNCTION(Runtime_MyRuntime) {
+2.  SealHandleScope shs(isolate);
+3.  DCHECK_EQ(1, args.length());
+
+4. //这是功能区，
+
+
+5.  return ReadOnlyRoots(isolate).undefined_value();
+6.}
+```
+行1，2是约定，需要使用`RUNTIME_FUNCTION`宏模板和传入`isolate`，行3是参数个数的检测，`MyRuntime`在前面说明了一个参数，一个返回值，所以行3的检测是`args.length()  ==1`，这行也可以省略；行5是返回值，返回空值。行4是功能区，要实现的功能，看看其它runtime的写法，就知道如何实现自己的功能了。  
+我用runtime函数最多的场景是对Bytecodehandler进行状态分析，因为Bytecodehanlder是Builtins(汇编实现)，所以利用这方式充当断点，观察执行状态。下面说明如何在一个Bytecodehandler中调用`MyRuntime`，调用方法：
+`CallRuntime(Runtime::kMyRuntime, context, your args0);`。下面给出一个事例：
+```c++
+IGNITION_HANDLER(LdaConstant, InterpreterAssembler) {
+  TNode<Object> constant = LoadConstantPoolEntryAtOperandIndex(0);
+  TNode<Context> context = GetContext();//这是我加的
+  SetAccumulator(constant);
+  CallRuntime(Runtime::kMyRuntime, context, constant);//这里也是，context是它的第一个参数，也是必须要用的
+  Dispatch();
+}
+```  
+`context`是传给`MyRuntime()`的第一个参数，这是格式要求，**注意：它不计在参数的数量中!** 通过下面的测试代码，对`MyRuntime`做测试：  
+```c++
+var s = "abcdef";
+word=s.indexOf('e');
+console.log(word)
+//分隔线.........
+         0000003D8069D776 @    0 : 12 00             LdaConstant [0]
+         0000003D8069D778 @    2 : 26 fa             Star r1
+         0000003D8069D77A @    4 : 0b                LdaZero
+         0000003D8069D77B @    5 : 26 f9             Star r2
+         0000003D8069D77D @    7 : 27 fe f8          Mov <closure>, r3
+         0000003D8069D780 @   10 : 61 2f 01 fa 03    CallRuntime [DeclareGlobals], r1-r3
+    0 E> 0000003D8069D785 @   15 : a7                StackCheck
+    7 S> 0000003D8069D786 @   16 : 81 01 00 00       CreateClosure [1], [0], #0
+         0000003D8069D78A @   20 : 15 02 02          StaGlobal [2], [2]
+         0000003D8069D78D @   23 : 26 fb             Star r0
+   46 S> 0000003D8069D78F @   25 : ab                Return
+```
+如图1，在`LdaConstant`中调用了`MyRuntime`函数，正好是我们加了`kMyRuntime`的第一条字节码，这里可以加入自定义功能用于观察字节码状态。  
+![avatar](f1.png)    
+其实，V8已经内置了几个用于调试的runtime功能：`DebugPrint`、`InterpreterTraceBytecodeEntry`、`InterpreterTraceBytecodeExit`等，下面跟踪字节码执行时最重要的两个函数`BytecodeEntry`和`PrintRegisters`的源码：
+```c++
+1.  void PrintRegisters(Isolate* isolate, std::ostream& os, bool is_input,
+2.                      interpreter::BytecodeArrayIterator&
+3.                          bytecode_iterator,  // NOLINT(runtime/references)
+4.                      Handle<Object> accumulator) {
+5.  //省略很.......
+6.    // Print the registers.
+7.    JavaScriptFrameIterator frame_iterator(isolate);
+8.    InterpretedFrame* frame =
+9.        reinterpret_cast<InterpretedFrame*>(frame_iterator.frame());
+10.    int operand_count = interpreter::Bytecodes::NumberOfOperands(bytecode);
+11.    for (int operand_index = 0; operand_index < operand_count; operand_index++) {
+12.      interpreter::OperandType operand_type =
+13.          interpreter::Bytecodes::GetOperandType(bytecode, operand_index);
+14.      bool should_print =
+15.          is_input
+16.              ? interpreter::Bytecodes::IsRegisterInputOperandType(operand_type)
+17.              : interpreter::Bytecodes::IsRegisterOutputOperandType(operand_type);
+18.      if (should_print) {
+19.        interpreter::Register first_reg =
+20.            bytecode_iterator.GetRegisterOperand(operand_index);
+21.        int range = bytecode_iterator.GetRegisterOperandRange(operand_index);
+22.        for (int reg_index = first_reg.index();
+23.             reg_index < first_reg.index() + range; reg_index++) {
+24.          Object reg_object = frame->ReadInterpreterRegister(reg_index);
+25.          os << "      [ " << std::setw(kRegFieldWidth)
+26.             << interpreter::Register(reg_index).ToString(
+27.                    bytecode_iterator.bytecode_array()->parameter_count())
+28.             << kArrowDirection;
+29.          reg_object.ShortPrint(os);
+30.          os << " ]" << std::endl;
+31.        }
+32.      }
+33.    }
+34.    if (FLAG_log_colour) {
+35.      os << kNormalColourCode;
+36.    }
+37.  }
+38.  //分隔......................... 
+39.   RUNTIME_FUNCTION(Runtime_InterpreterTraceBytecodeEntry) {
+40.     if (!FLAG_trace_ignition) {
+41.       return ReadOnlyRoots(isolate).undefined_value();
+42.     }
+43.     SealHandleScope shs(isolate);
+44.     DCHECK_EQ(3, args.length());
+45.     CONVERT_ARG_HANDLE_CHECKED(BytecodeArray, bytecode_array, 0);
+46.     CONVERT_SMI_ARG_CHECKED(bytecode_offset, 1);
+47.     CONVERT_ARG_HANDLE_CHECKED(Object, accumulator, 2);
+48.      int offset = bytecode_offset - BytecodeArray::kHeaderSize + kHeapObjectTag;
+49.      interpreter::BytecodeArrayIterator bytecode_iterator(bytecode_array);
+50.      AdvanceToOffsetForTracing(bytecode_iterator, offset);
+51.      if (offset == bytecode_iterator.current_offset()) {
+52.        StdoutStream os;
+53.        // Print bytecode.
+54.        const uint8_t* base_address = reinterpret_cast<const uint8_t*>(
+55.            bytecode_array->GetFirstBytecodeAddress());
+56.        const uint8_t* bytecode_address = base_address + offset;
+57.        os << " -> " << static_cast<const void*>(bytecode_address) << " @ "
+58.           << std::setw(4) << offset << " : ";
+59.        interpreter::BytecodeDecoder::Decode(os, bytecode_address,
+60.                                             bytecode_array->parameter_count());
+61.        os << std::endl;
+62.        // Print all input registers and accumulator.
+63.        PrintRegisters(isolate, os, true, bytecode_iterator, accumulator);
+64.        os << std::flush;
+65.      }
+66.      return ReadOnlyRoots(isolate).undefined_value();
+67.    }
+```  
+笔者以为，在V8学习过程，尤其入门阶段，面临的一个最大问题是如何跟踪Bytecode的执行过程，上面代码`InterpreterTraceBytecodeEentry`和`InterpreterTraceBytecodeExit`（没有给出）在每条字节码执行的前后输出寄存器状态，`PrintRegisters()`方法用于输出寄存器值，该方法的重要之处是它写明了如何在V8中使用`print`输出到控制台。当对V8的Bytecode有更多的跟踪需求时，可以利用自定义runtime方法，在任意位置下钩子，以各种方式输出一切想看的状态。此外，我总结了一套在汇编级跟踪Bytecode的方法，此方法更加详细地看到V8的执行过程，该方法过于依赖汇编，已经脱离了V8的学习范畴，所以没发表文章，有需要的朋友私信我。  
+好了，今天到这里，下次见。   
+
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap15-1024/f1.png b/chap15-1024/f1.png
new file mode 100644
index 0000000..fae1acf
Binary files /dev/null and b/chap15-1024/f1.png differ
diff --git a/chap16-1025/README.md b/chap16-1025/README.md
new file mode 100644
index 0000000..df22928
--- /dev/null
+++ b/chap16-1025/README.md
@@ -0,0 +1,238 @@
+# 《Chrome V8原理讲解》第十六篇 运行时辅助类，详解加载与调用过程
+ 
+![avatar](../v8.png)  
+# 前言  
+本系列的前十三篇文章，讲解了V8执行Javascript时最基础的工作流程和原理，包括词法分析、语法分析、字节码生成、Builtins方法、ignition执行单元，等等，达到了从零做起，入门学习的目的。  
+接下来的文章将以问题为导向讲解V8源码，例如：以闭包技术、或垃圾回收（GC）为专题讲解V8中的相关源码。V8代码过于庞大，以问题为导向可以使得学习主题更加明确、效果更好。同时，我争取做到每篇文章是一个独立的知识点，方便大家阅读。  
+读者可以把想学的内容在文末评论区留言，我汇总后出专题文章。  
+# 1 摘要 
+运行时辅助类（Runtime）在Javascript执行期提供众多辅助功能，如属性访问，新建对象、正则表达式等。上篇文章对“Runtime是什么？怎么用了？”做了详细介绍，本文将重点说明“他是怎么来的？他存储在哪？”，也就是Runtime在V8中的初始化过程，初始化完后的存储位置，以及在`BytecodeHandler`中的调用细节。
+# 2 Runtime初始过程  
+Runtime属于V8的基础组件，在创建Isolate时完成初始化，下面是初始化阶段的源码:  
+```c++
+1.   bool Isolate::Init(ReadOnlyDeserializer* read_only_deserializer,
+2.                      StartupDeserializer* startup_deserializer) {
+3.     TRACE_ISOLATE(init);
+4.     const bool create_heap_objects = (read_only_deserializer == nullptr);
+5.     // We either have both or neither.
+6.     DCHECK_EQ(create_heap_objects, startup_deserializer == nullptr);
+7.     base::ElapsedTimer timer;
+8.    //省略很多...............................
+9.      handle_scope_implementer_ = new HandleScopeImplementer(this);
+10.      load_stub_cache_ = new StubCache(this);
+11.      store_stub_cache_ = new StubCache(this);
+12.      materialized_object_store_ = new MaterializedObjectStore(this);
+13.      regexp_stack_ = new RegExpStack();
+14.      regexp_stack_->isolate_ = this;
+15.      date_cache_ = new DateCache();
+16.      heap_profiler_ = new HeapProfiler(heap());
+17.      interpreter_ = new interpreter::Interpreter(this);
+18.      compiler_dispatcher_ =
+19.          new CompilerDispatcher(this, V8::GetCurrentPlatform(), FLAG_stack_size);
+20.      // Enable logging before setting up the heap
+21.      logger_->SetUp(this);
+22.      {  // NOLINT
+23.        ExecutionAccess lock(this);
+24.        stack_guard()->InitThread(lock);
+25.      }
+26.      // SetUp the object heap.
+27.      DCHECK(!heap_.HasBeenSetUp());
+28.      heap_.SetUp();
+29.      ReadOnlyHeap::SetUp(this, read_only_deserializer);
+30.      heap_.SetUpSpaces();
+31.      isolate_data_.external_reference_table()->Init(this);
+32.      //省略很多...................
+33.    }
+```  
+上述代码是`isolate`的初始化入口，行10~20包括了很多重要组件的初始化工作，例如`Interpreter`、`compiler_dispatcher`等等，后续文章都会讲到。Runtime的初始化由`external`负责，代码31行`Init()`方法中完成相关工作，源码如下:  
+```c++
+1.  void ExternalReferenceTable::Init(Isolate* isolate) {
+2.    int index = 0;
+3.    // kNullAddress is preserved through serialization/deserialization.
+4.    Add(kNullAddress, &index);
+5.    AddReferences(isolate, &index);
+6.    AddBuiltins(&index);
+7.    AddRuntimeFunctions(&index);
+8.    AddIsolateAddresses(isolate, &index);
+9.    AddAccessors(&index);
+10.    AddStubCache(isolate, &index);
+11.    AddNativeCodeStatsCounters(isolate, &index);
+12.    is_initialized_ = static_cast<uint32_t>(true);
+13.    CHECK_EQ(kSize, index);
+14.  }
+```  
+代码4行~11行是由`external`类负责管理的初始化，这其中包括了我们多次提到的`Builtins`。`AddRuntimeFunctions(&index)`是Runtime的初始化函数，代码如下：  
+```c++
+1.  void ExternalReferenceTable::AddRuntimeFunctions(int* index) {
+2.    CHECK_EQ(kSpecialReferenceCount + kExternalReferenceCount +
+3.                 kBuiltinsReferenceCount,
+4.             *index);
+5.    static constexpr Runtime::FunctionId runtime_functions[] = {
+6.  #define RUNTIME_ENTRY(name, ...) Runtime::k##name,
+7.        FOR_EACH_INTRINSIC(RUNTIME_ENTRY)
+8.  #undef RUNTIME_ENTRY
+9.    };
+10.    for (Runtime::FunctionId fId : runtime_functions) {
+11.      Add(ExternalReference::Create(fId).address(), index);
+12.    }
+13.    CHECK_EQ(kSpecialReferenceCount + kExternalReferenceCount +
+14.                 kBuiltinsReferenceCount + kRuntimeReferenceCount,
+15.             *index);
+16.  }
+```  
+它只有一个参数index，在本文所用的V8版本中它的值是430，代表下标，`ExternalReferenceTable`是表结构，它的核心成员是地址指针数组（ref_addr_），index代表它的下标，表示Runtime函数在`ExternalReferenceTable`成员变量ref_addr_中的位置，本文所用V8中有468个Runtime方法，初始化完成后存储在`ref_addr_`的430~430+468-1这个区间内。`ExternalReferenceTable`表结构非常简单，稍后给出。  
+![avatar](f1.png)  
+代码5行定义了Runtime的枚举变量，其中涉及的宏模板请自行展开，图1给出部分枚举变量。代码11行通过`for`循环添加函数，`Create()`方法根据`Runtime Id`创建表项，最终添加到`ExternalReferenceTable`表中，代码如下：  
+```c++
+1.  ExternalReference ExternalReference::Create(Runtime::FunctionId id) {
+2.    return Create(Runtime::FunctionForId(id));
+3.  }
+4.  //分隔线........................
+5.  const Runtime::Function* Runtime::FunctionForId(Runtime::FunctionId id) {
+6.    return &(kIntrinsicFunctions[static_cast<int>(id)]);
+7.  }
+8.  //分隔线.......................
+9.  ExternalReference ExternalReference::Create(const Runtime::Function* f) {
+10.    return ExternalReference(
+11.        Redirect(f->entry, BuiltinCallTypeForResultSize(f->result_size)));
+12.  }
+```  
+上述代码是三个函数，依次调用。第一个函数`Create(Runtime::FunctionId id)`的参数是图1中的枚举值；第二个函数`FunctionForId(Runtime::FunctionId id)`的返回值是`kIntrinsicFunctions`类型的数据，该数据是以下几个宏代码的展开结果。
+```c++
+#define FUNCTION_ADDR(f) (reinterpret_cast<v8::internal::Address>(f))
+#define F(name, number_of_args, result_size)                                  \
+  {                                                                           \
+    Runtime::k##name, Runtime::RUNTIME, #name, FUNCTION_ADDR(Runtime_##name), \
+        number_of_args, result_size                                           \
+  }                                                                           \
+  ,
+
+
+#define I(name, number_of_args, result_size)                       \
+  {                                                                \
+    Runtime::kInline##name, Runtime::INLINE, "_" #name,            \
+        FUNCTION_ADDR(Runtime_##name), number_of_args, result_size \
+  }                                                                \
+  ,
+
+static const Runtime::Function kIntrinsicFunctions[] = {
+    FOR_EACH_INTRINSIC(F) FOR_EACH_INLINE_INTRINSIC(I)};
+
+#undef I
+#undef F
+```  
+`kIntrinsicFunctions`数据是什么类型？它是数组，每个成员又是`函数名，参数个数，返回值个数`组成的另一个数组。上一篇文章中，我定义的`MyRuntime`方法，格式是：`F(MyRuntime,1,1)`，正好和这个数据格式对应，下面是`kIntrinsicFunctions`展开的样例：  
+```c++
+kIntrinsicFunctions []={
+  //.....................
+  {                                                                           
+    Runtime::kDebugPrint, Runtime::RUNTIME, "DebugPrint", (reinterpret_cast<v8::internal::Address>(Runtime_DebugPrint)), 
+        1, 1 
+  },
+  //.....................     
+``` 
+`kIntrinsicFunctions`是一个二维数组，上述代码展示了其中的一组数据。下面是`void ExternalReferenceTable::AddRuntimeFunctions(int* index)`方法中11行`Add()`方法的源码：  
+```c++
+void ExternalReferenceTable::Add(Address address, int* index) {
+  ref_addr_[(*index)++] = address;
+}
+```  
+`index`每次添加后会增1，`ref_addr_`是什么呢？它是`ExternalReferenceTable`的成员变量，地址指针数组，下面是`ExternalReferenceTable`源码：  
+```c++
+1.  class ExternalReferenceTable {
+2.   public:
+3.    static constexpr int kSpecialReferenceCount = 1;
+4.    static constexpr int kExternalReferenceCount =
+5.        ExternalReference::kExternalReferenceCount;
+6.    static constexpr int kBuiltinsReferenceCount =
+7.  #define COUNT_C_BUILTIN(...) +1
+8.        BUILTIN_LIST_C(COUNT_C_BUILTIN);
+9.  #undef COUNT_C_BUILTIN
+10.     static constexpr int kRuntimeReferenceCount =
+11.         Runtime::kNumFunctions -
+12.         Runtime::kNumInlineFunctions;  // Don't count dupe kInline... functions.
+13.     static constexpr int kIsolateAddressReferenceCount = kIsolateAddressCount;
+14.     static constexpr int kAccessorReferenceCount =
+15.         Accessors::kAccessorInfoCount + Accessors::kAccessorSetterCount;
+16.     static constexpr int kStubCacheReferenceCount = 12;
+17.     static constexpr int kStatsCountersReferenceCount =
+18.   #define SC(...) +1
+19.         STATS_COUNTER_NATIVE_CODE_LIST(SC);
+20.   #undef SC
+21.   //..............省略很多............................
+22.     ExternalReferenceTable() = default;
+23.     void Init(Isolate* isolate);
+24.    private:
+25.     void Add(Address address, int* index);
+26.     void AddReferences(Isolate* isolate, int* index);
+27.     void AddBuiltins(int* index);
+28.     void AddRuntimeFunctions(int* index);
+29.     void AddIsolateAddresses(Isolate* isolate, int* index);
+30.     void AddAccessors(int* index);
+31.     void AddStubCache(Isolate* isolate, int* index);
+32.     Address GetStatsCounterAddress(StatsCounter* counter);
+33.     void AddNativeCodeStatsCounters(Isolate* isolate, int* index);
+34.     STATIC_ASSERT(sizeof(Address) == kEntrySize);
+35.     Address ref_addr_[kSize];
+36.     static const char* const ref_name_[kSize];
+37.     uint32_t is_initialized_ = 0;
+38.     uint32_t dummy_stats_counter_ = 0;
+39.     DISALLOW_COPY_AND_ASSIGN(ExternalReferenceTable);
+40.   };
+```  
+代码7行给出了`Builtin`统计时使用的宏模板，代码行25~35说明了`ExternalReferenceTable`负责初始化和管理哪些数据，初始化后的数据，也就是函数地址，保存在`ref_addr_`数组中，见代码35行，它的类型`Address`是`using Address = uintptr_t;`，`typedef unsigned __int64  uintptr_t;`。  
+![vavtar](f2.png)  
+图2中给出了三个关键信息，`Add()`方法的调用位置，对应的函数调用堆栈，以及展示了部分`ref_addr_`的内容。    
+总结，`ExternalReferenceTable`最重要的成员是`ref_addr_`，它本质就是一个指针数组，Rumtime函数保存在下标430开始的成员中，调用时用下标值索引函数地址。  
+# 3 Runtime调用  
+`CallRuntime()`或`CallRuntimeWithCEntry()`负责调用`Runtime`功能，上篇文章给出了调用样例并做了实验，本文不再赘述。我们以`CallRuntime()`为例讲解，源码如下：  
+```c++
+1.   template <class... TArgs>
+2.   TNode<Object> CallRuntime(Runtime::FunctionId function,
+3.                             SloppyTNode<Object> context, TArgs... args) {
+4.     return CallRuntimeImpl(function, context,
+5.                            {implicit_cast<SloppyTNode<Object>>(args)...});
+6.   }
+7.  //分隔线.........................
+8.   TNode<Object> CodeAssembler::CallRuntimeImpl(
+9.       Runtime::FunctionId function, TNode<Object> context,
+10.        std::initializer_list<TNode<Object>> args) {
+11.      int result_size = Runtime::FunctionForId(function)->result_size;
+12.      TNode<Code> centry =
+13.          HeapConstant(CodeFactory::RuntimeCEntry(isolate(), result_size));
+14.      return CallRuntimeWithCEntryImpl(function, centry, context, args);
+15.    }
+16.  //分隔线.........................
+17.    TNode<Type> HeapConstant(Handle<Type> object) {
+18.        return UncheckedCast<Type>(UntypedHeapConstant(object));
+19.      }
+20.  //分隔线.........................
+21.  TNode<Object> CodeAssembler::CallRuntimeWithCEntryImpl(
+22.        Runtime::FunctionId function, TNode<Code> centry, TNode<Object> context,
+23.        std::initializer_list<TNode<Object>> args) {
+24.      constexpr size_t kMaxNumArgs = 6;
+25.      DCHECK_GE(kMaxNumArgs, args.size());
+26.      int argc = static_cast<int>(args.size());
+27         auto call_descriptor = Linkage::GetRuntimeCallDescriptor(zone(), function, argc, Operator::kNoProperties,
+                      Runtime::MayAllocate(function) ? CallDescriptor::kNoFlags
+                                     : CallDescriptor::kNoAllocate);
+1.       for (auto arg : args) inputs.Add(arg);
+2.       inputs.Add(ref);
+3.       inputs.Add(arity);
+4.       inputs.Add(context);
+5.       CallPrologue();
+6.       Node* return_value =
+7.           raw_assembler()->CallN(call_descriptor, inputs.size(), inputs.data());
+8.       HandleException(return_value);
+9.       CallEpilogue();
+10.      return UncheckedCast<Object>(return_value);
+11.    }
+```  
+代码2行，`CallRuntime()`声明中，可以看到它有三个参数，第一个是FunctionId枚举类型，前面提到过；第二个参数是context，第三参数`args`是传给Runtime函数的参数列表。`CallRuntime()`调用`CallRuntimeImpl()`,在`CallRuntimeImpl`内部读取堆中的常量数据（HeapConstant），代码18行，该数据中保存了函数与下标的对应关系，用`FunctionId`在该表中查到对应的函数地址，代码27行建立调用描述符(参见之前的文章)，最终在代码34行调用Runtime函数。  
+上述代码是Builtin，不能在C++级别做Debug，无法给出调用堆栈等调试信息。也许你会有疑问：为什么不用上篇文章中提到的`RUNTIME_DebugPrint`或是自定义Runtime功能做断点？答：我们现在讲的就是Runtime的调用过程，没办法使用Runtime调试自己:(((。  
+要调试也是有办法的，汇编调试，汇编调试超出了V8的学习范围，我就不列出来了，对此感兴趣的朋友，评论区私信我。  
+**最后，纠正《第十五篇》中的一个错误，我曾写到：“context是传给MyRuntime()的第一个参数，这是格式要求，注意：它不计在参数的数量中! 通过下面的测试代码，对MyRuntime做测试：”。** 正确的解释是：`context`不是MyRuntime()的第一个参数，它是`CallRuntime()`的第二参数，与`MyRuntime()`无关。     
+好了，今天到这里，下次见。   
+
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap16-1025/f1.png b/chap16-1025/f1.png
new file mode 100644
index 0000000..4962f7a
Binary files /dev/null and b/chap16-1025/f1.png differ
diff --git a/chap16-1025/f2.png b/chap16-1025/f2.png
new file mode 100644
index 0000000..8b76951
Binary files /dev/null and b/chap16-1025/f2.png differ
diff --git a/chap17-1026/README.md b/chap17-1026/README.md
new file mode 100644
index 0000000..2036bce
--- /dev/null
+++ b/chap17-1026/README.md
@@ -0,0 +1,244 @@
+# 《Chrome V8原理讲解》第十七篇 JS对象的内存布局与创建过程
+
+![avatar](../v8.png)  
+# 前言  
+本系列的前十三篇文章，讲解了V8执行Javascript时最基础的工作流程和原理，包括词法分析、语法分析、字节码生成、Builtins方法、ignition执行单元，等等，达到了从零做起，入门学习的目的。  
+接下来的文章将以问题为导向讲解V8源码，例如：以闭包技术、或垃圾回收（GC）为专题讲解V8中的相关源码。V8代码过于庞大，以问题为导向可以使得学习主题更加明确、效果更好。同时，我争取做到每篇文章是一个独立的知识点，方便大家阅读。  
+读者可以把想学的内容在文末评论区留言，我汇总后出专题文章。  
+# 1 摘要 
+《javascript高级程序设计》中对JS对象有这样的描述:“ECMA-262 将对象定义为一组属性的无序集合。严格来说，这意味着对象就是一组没有特定顺序的值。对象的每个属性或方法都由一个名称来标识，这个名称映射到一个值。可以把ECMAScript的对象想象成一张散列表，其中的内容就是一组名/值对，值可以是数据或者函数。”v8官方文档提到这样的描述：“出于性能、亦或代码设计的考虑，V8中对数据类型的设计做了详细分类，对JS对象内部的数据成员也做了不同的设计”。  
+本文深入V8内部，详细剖析JS对象的创建过程，讲解JS对象内部成员的组成方式、内存布局，以及重要数据结构。本文内容组织方式：V8中JS对象的重要概念、成员组成和内存布局（章节2）;JS对象创建过程（章节2）。
+# 2 JS对象  
+在V8中，JS对象的每个成员、方法都有详细的分类和内存组织规则，内部成员从数据类型看分为两大类，元素类（Element）和属性类（Property），如图1。  
+![avatar](f1.png)  
+图1（来自V8官方）中，可以看到元素和属性分开存储，原因是为提高效率。Element成员可以利用下标访问，它存在连续的地址空间中。Property成员，也是存在连的地址空间中,但不能使用下标访问成员，需要借助Map（HiddenClass）访问，Map记载了数据的描述符，通俗地说，Map描述数据的形状,数据访问方式等，参见第十四篇文章。元素类数据不需要借助Map，他的访问效率要高一些，如图2。  
+![avatar](f2.png)  
+图2（出处同图1）中，除了Element和Property之外，还有In-object property，它与前面提到的Property不同之处是访问时不需要借助Map，这提高了访问效率，但In-object property的数量有限，优先使用In-object property,用完之后使用前面提到的“正常”Property进行存储。
+![avatar](f3.png)  
+图3（出处同图1），JS对象成员的访问方式有三种：  
+**（1）** In-Object，JS对象负责维护地址，它直接存在JS对象中；    
+**（2）** Slow方式，需要借助Map访问的元素；  
+**（3）** Self-dict，JS对象自己维护地址，不需要借助Map，采用字典方式存储数据。
+self-dict是效率最差的存储方式，当数据很多并且不连续时，V8会放弃Map机制，改用self-dict方式存储，稍后在源码中做详细解释。  
+图4给出一个JS对象的内存部局。 
+![avatar](f4.png)   
+申请JS对象时，对象的首地址指向Map（Map大小为：80byte），存在多个JS对象同共Map的情况，对象中还包括了Property back store和Element back store指针，其它的依据情况而定，什么样的情况稍后见代码解释。  
+JS对象的成员方法存在哪里呢？文章开头处提到：它是普通的Property成员。通过下面的测试代码解释成员方法的存储方式。  
+```c++
+1.  function person(name) {
+2.      this.name=name;
+3.  	this.sayname=function(){console.log(this.name);}
+4.  }
+5.  worker = new person("Nicholas");
+6.  worker.sayname();
+7.  //分隔线..............................................................
+8.  //分隔线..............................................................
+9.  Bytecode Age: 0
+10.           000001DAA2FA1E96 @    0 : 13 00             LdaConstant [0]
+11.           000001DAA2FA1E98 @    2 : c2                Star1
+12.           000001DAA2FA1E99 @    3 : 19 fe f8          Mov <closure>, r2
+13.      0 E> 000001DAA2FA1E9C @    6 : 64 51 01 f9 02    CallRuntime [DeclareGlobals], r1-r2
+14.    100 S> 000001DAA2FA1EA1 @   11 : 21 01 00          LdaGlobal [1], [0]
+15.           000001DAA2FA1EA4 @   14 : c2                Star1
+16.           000001DAA2FA1EA5 @   15 : 13 02             LdaConstant [2]
+17.           000001DAA2FA1EA7 @   17 : c1                Star2
+18.           000001DAA2FA1EA8 @   18 : 0b f9             Ldar r1
+19.    109 E> 000001DAA2FA1EAA @   20 : 68 f9 f8 01 02    Construct r1, r2-r2, [2]
+20.    107 E> 000001DAA2FA1EAF @   25 : 23 03 04          StaGlobal [3], [4]
+21.    134 S> 000001DAA2FA1EB2 @   28 : 21 03 06          LdaGlobal [3], [6]
+22.           000001DAA2FA1EB5 @   31 : c1                Star2
+23.    141 E> 000001DAA2FA1EB6 @   32 : 2d f8 04 08       LdaNamedProperty r2, [4], [8]
+24.           000001DAA2FA1EBA @   36 : c2                Star1
+25.    141 E> 000001DAA2FA1EBB @   37 : 5c f9 f8 0a       CallProperty0 r1, r2, [10]
+26.           000001DAA2FA1EBF @   41 : c3                Star0
+27.    151 S> 000001DAA2FA1EC0 @   42 : a8                Return
+28.  Constant pool (size = 5)
+29.  000001DAA2FA1E29: [FixedArray] in OldSpace
+30.   - map: 0x024008ac12c1 <Map>
+31.   - length: 5
+32.             0: 0x01daa2fa1d11 <FixedArray[2]>
+33.             1: 0x01daa2fa1c09 <String[6]: #person>
+34.             2: 0x01daa2fa1c39 <String[8]: #Nicholas>
+35.             3: 0x01daa2fa1c21 <String[6]: #worker>
+36.             4: 0x01daa2fa1c51 <String[7]: #sayname>
+```  
+上半部分是js源码，下半部分是Bytecode。代码19行`Construct`构建JS对象`person`，并传递参数`Nicholas`，代码16，17行从常量池中取出`Nicholas`并存储到r2寄存器。而`sayname`成员是一个方法，因为lazy编译的原因，此时不做编译，而是在代码6行执行时才做编译，如下给`sayname`成员编译后的字节码：  
+```c++
+Bytecode Age: 0
+   29 S> 000001DAA2FA21AE @    0 : 0b 03             Ldar a0
+   38 E> 000001DAA2FA21B0 @    2 : 32 02 00 00       StaNamedProperty <this>, [0], [0]
+   47 S> 000001DAA2FA21B4 @    6 : 7f 01 00 01       CreateClosure [1], [0], #1
+   59 E> 000001DAA2FA21B8 @   10 : 32 02 02 02       StaNamedProperty <this>, [2], [2]
+         000001DAA2FA21BC @   14 : 0e                LdaUndefined
+   97 S> 000001DAA2FA21BD @   15 : a8                Return
+Constant pool (size = 3)
+000001DAA2FA2151: [FixedArray] in OldSpace
+ - map: 0x024008ac12c1 <Map>
+ - length: 3
+           0: 0x024008ac5379 <String[4]: #name>
+           1: 0x01daa2fa20f9 <SharedFunctionInfo sayname>
+           2: 0x01daa2fa1c51 <String[7]: #sayname>
+```  
+在上面的字节码中，看不到`console.log`，因为在此阶段V8是要执行sayname，虽然我们知道sayname的主体功能只有`console.log`，但V8还没有执行到它，所以不编译。不执行时不编译，这就是lazy思想。  
+上述代码可以看出：**`sayname`虽然是一个成员方法，但在JS对象内部，它只是普通的Property成员。**   
+# 3 JS对象的创建过程  
+使用上面的测试用例，下面是创建`person`对象的源码位置：  
+```c++
+1.  RUNTIME_FUNCTION(Runtime_NewObject) {
+2.    HandleScope scope(isolate);
+3.    DCHECK_EQ(2, args.length());
+4.    CONVERT_ARG_HANDLE_CHECKED(JSFunction, target, 0);
+5.    CONVERT_ARG_HANDLE_CHECKED(JSReceiver, new_target, 1);
+6.    RETURN_RESULT_OR_FAILURE(
+7.        isolate,
+8.        JSObject::New(target, new_target, Handle<AllocationSite>::null()));
+9.  }
+10.  //分隔线.....................................
+11.  MaybeHandle<JSObject> JSObject::New(Handle<JSFunction> constructor,
+12.                                      Handle<JSReceiver> new_target,
+13.                                      Handle<AllocationSite> site) {
+14.    Isolate* const isolate = constructor->GetIsolate();
+15.    DCHECK(constructor->IsConstructor());
+16.    DCHECK(new_target->IsConstructor());
+17.    DCHECK(!constructor->has_initial_map() ||
+18.           !InstanceTypeChecker::IsJSFunction(
+19.               constructor->initial_map().instance_type()));
+20.    Handle<Map> initial_map;
+21.    ASSIGN_RETURN_ON_EXCEPTION(
+22.        isolate, initial_map,
+23.        JSFunction::GetDerivedMap(isolate, constructor, new_target), JSObject);
+24.    int initial_capacity = V8_ENABLE_SWISS_NAME_DICTIONARY_BOOL
+25.                               ? SwissNameDictionary::kInitialCapacity
+26.                               : NameDictionary::kInitialCapacity;
+27.    Handle<JSObject> result = isolate->factory()->NewFastOrSlowJSObjectFromMap(
+28.        initial_map, initial_capacity, AllocationType::kYoung, site);
+29.    isolate->counters()->constructed_objects()->Increment();
+30.    isolate->counters()->constructed_objects_runtime()->Increment();
+31.    return result;
+32.  }
+```  
+创建过程由`RUNTIME_FUNCTION(Runtime_NewObject)`开始，它是一个宏模板，在上篇文章中讲过，本文不在赘述。`JSObject::New()`方法新建JS对象，进入` JSFunction::GetDerivedMap(isolate, constructor, new_target), JSObject);`方法，源码如下：  
+```c++
+1.  MaybeHandle<Map> JSFunction::GetDerivedMap(Isolate* isolate,
+2.                                             Handle<JSFunction> constructor,
+3.                                             Handle<JSReceiver> new_target) {
+4.    EnsureHasInitialMap(constructor);
+5.    Handle<Map> constructor_initial_map(constructor->initial_map(), isolate);
+6.    if (*new_target == *constructor) return constructor_initial_map;
+7.    Handle<Map> result_map;
+8.    if (new_target->IsJSFunction()) {
+9.      Handle<JSFunction> function = Handle<JSFunction>::cast(new_target);
+10.       if (FastInitializeDerivedMap(isolate, function, constructor,
+11.                                    constructor_initial_map)) {
+12.         return handle(function->initial_map(), isolate);
+13.       }
+14.     }
+15.     Handle<Object> prototype;
+16.     if (new_target->IsJSFunction()) {
+17.       Handle<JSFunction> function = Handle<JSFunction>::cast(new_target);
+18.       if (function->has_prototype_slot()) {
+19.         // Make sure the new.target.prototype is cached.
+20.         EnsureHasInitialMap(function);
+21.         prototype = handle(function->prototype(), isolate);
+22.       } else {
+23.         // No prototype property, use the intrinsict default proto further down.
+24.         prototype = isolate->factory()->undefined_value();
+25.       }
+26.     } else {
+27.  //省略很多..............
+28.     }
+29.     if (!prototype->IsJSReceiver()) {
+30.  //省略很多..............
+31.     }
+32.     Handle<Map> map = Map::CopyInitialMap(isolate, constructor_initial_map);
+33.     map->set_new_target_is_base(false);
+34.     CHECK(prototype->IsJSReceiver());
+35.     if (map->prototype() != *prototype)
+36.       Map::SetPrototype(isolate, map, Handle<HeapObject>::cast(prototype));
+37.     map->SetConstructor(*constructor);
+38.     return map;
+39.   }
+```  
+`Handle<JSFunction> constructor`是构造函数person（测试代码），代码16行时构造函数的Map基本完成，这里设置prototype，在这里安装prototype.代码4行，`EnsureHasInitialMap(constructor);`很重要，它的作用是计算构造函数constructor的形状并生成Map。然后使用这个Map申请内存、创建对象的实例`worker`（测试样例代码），计算的过程需要对它进行编译（之前没有编译过），代码如下：  
+```c++
+1.  void JSFunction::EnsureHasInitialMap(Handle<JSFunction> function) {
+2.    DCHECK(function->has_prototype_slot());
+3.    DCHECK(function->IsConstructor() ||
+4.           IsResumableFunction(function->shared().kind()));
+5.    if (function->has_initial_map()) return;
+6.    Isolate* isolate = function->GetIsolate();
+7.    int expected_nof_properties =
+8.        CalculateExpectedNofProperties(isolate, function);
+9.    if (function->has_initial_map()) return;
+10.    InstanceType instance_type;
+11.    if (IsResumableFunction(function->shared().kind())) {
+12.      instance_type = IsAsyncGeneratorFunction(function->shared().kind())
+13.                          ? JS_ASYNC_GENERATOR_OBJECT_TYPE
+14.                          : JS_GENERATOR_OBJECT_TYPE;
+15.    } else {
+16.      instance_type = JS_OBJECT_TYPE;
+17.    }
+18.    int instance_size;
+19.    int inobject_properties;
+20.    CalculateInstanceSizeHelper(instance_type, false, 0, expected_nof_properties,
+21.                                &instance_size, &inobject_properties);
+22.    Handle<Map> map = isolate->factory()->NewMap(instance_type, instance_size,
+23.                                                 TERMINAL_FAST_ELEMENTS_KIND,
+24.                                                 inobject_properties);
+25.    Handle<HeapObject> prototype;
+26.    if (function->has_instance_prototype()) {
+27.      prototype = handle(function->instance_prototype(), isolate);
+28.    } else {
+29.      prototype = isolate->factory()->NewFunctionPrototype(function);
+30.    }
+31.    DCHECK(map->has_fast_object_elements());
+32.    DCHECK(prototype->IsJSReceiver());
+33.    JSFunction::SetInitialMap(isolate, function, map, prototype);
+34.    map->StartInobjectSlackTracking();
+35.  }
+```  
+代码5行，如果已经有Map，不用再计算了，返回。代码7行，计算构造函数的属性值，这里进行编译。代26~30行，生成prototype（注意区分：这里是生成，然后才是前面提到的设置和安全），构造函数是第一次生成，没有prototype，进入代码29行。注意： 这里可以看出，同一个构函数的不同实例之间是共用一个prototype，因为prototype是设置在构造函数person上，我们用person实例多个对象时，只有在person初次生成时才执行代码29行。    
+再来看代码7行，源码如下：  
+```c++
+1.  int JSFunction::CalculateExpectedNofProperties(Isolate* isolate,
+2.                                                 Handle<JSFunction> function) {
+3.    int expected_nof_properties = 0;
+4.    for (PrototypeIterator iter(isolate, function, kStartAtReceiver);
+5.         !iter.IsAtEnd(); iter.Advance()) {
+6.      Handle<JSReceiver> current =
+7.          PrototypeIterator::GetCurrent<JSReceiver>(iter);
+8.      if (!current->IsJSFunction()) break;
+9.      Handle<JSFunction> func = Handle<JSFunction>::cast(current);
+10.      Handle<SharedFunctionInfo> shared(func->shared(), isolate);
+11.      IsCompiledScope is_compiled_scope(shared->is_compiled_scope(isolate));
+12.      if (is_compiled_scope.is_compiled() ||
+13.          Compiler::Compile(isolate, func, Compiler::CLEAR_EXCEPTION,
+14.                            &is_compiled_scope)) {
+15.        DCHECK(shared->is_compiled());
+16.        int count = shared->expected_nof_properties();
+17.        if (expected_nof_properties <= JSObject::kMaxInObjectProperties - count) {
+18.          expected_nof_properties += count;
+19.        } else {
+20.          return JSObject::kMaxInObjectProperties;
+21.        }
+22.      } else {
+23.        continue;
+24.      }
+25.    }
+26.    if (expected_nof_properties > 0) {
+27.      expected_nof_properties += 8;
+28.      if (expected_nof_properties > JSObject::kMaxInObjectProperties) {
+29.        expected_nof_properties = JSObject::kMaxInObjectProperties;
+30.      }
+31.    }
+32.    return expected_nof_properties;
+33.  }
+```  
+`Handle<JSFunction> function`是构造函数person，代码13行进行编译并计算对象的属性值数量。代码28行，会与MaxInObject比较，如果大于MaxInObject，那么属性值数量就是MaxInObject。前面提到JS对象中In-Object数量有限，MaxInObject正是它的最大数量。多出的属性值在后面会作处理----放入图1的属性值存储区。  
+回到`JSObject::New()`方法中代码27行，用Map去申请JS对象的内存，后面就是对象实例化的参数设置等等，请读者根据图5的函数堆栈自行跟踪。  
+![avatar](f5.png)    
+
+好了，今天到这里，下次见。   
+
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap17-1026/f1.png b/chap17-1026/f1.png
new file mode 100644
index 0000000..b1515e0
Binary files /dev/null and b/chap17-1026/f1.png differ
diff --git a/chap17-1026/f2.png b/chap17-1026/f2.png
new file mode 100644
index 0000000..3863b32
Binary files /dev/null and b/chap17-1026/f2.png differ
diff --git a/chap17-1026/f3.png b/chap17-1026/f3.png
new file mode 100644
index 0000000..3250f9f
Binary files /dev/null and b/chap17-1026/f3.png differ
diff --git a/chap17-1026/f4.png b/chap17-1026/f4.png
new file mode 100644
index 0000000..bf33717
Binary files /dev/null and b/chap17-1026/f4.png differ
diff --git a/chap17-1026/f5.png b/chap17-1026/f5.png
new file mode 100644
index 0000000..33d9580
Binary files /dev/null and b/chap17-1026/f5.png differ
diff --git a/chap18-1031/README.md b/chap18-1031/README.md
new file mode 100644
index 0000000..9b9d31a
--- /dev/null
+++ b/chap18-1031/README.md
@@ -0,0 +1,168 @@
+# 《Chrome V8原理讲解》第十八篇 利用汇编看V8，洞察看不见的行为
+![avatar](../v8.png)  
+  
+# 前言  
+我认为，汇编分析无疑是调试v8的终级武器，当用C++调试无法获取更详细的信息时，汇编分析是最好的帮手，但如果不研究v8字节码或挖漏洞等，此文也许没必要看。本文与第十篇文章讲的是同一件事，但本文讲的方法能让你看到更多更详细的V8内部信息，算是第十篇文章的高配版。  
+
+# 1 摘要  
+图1是字节码（Bytecode）的执行示意图，说明了JavaScript字节码的解释执行（interpreter）过程，描绘Javascript语言这图够足用，但对学习V8源码来说，图1不够详细，它隐藏了解释器（Ignition）的工作流程，没有说明字节码的加载（load）和调度(dispatch)细节，等等。本文在图1基础上进一步深入，拆解字节码的解释细节，包括：Builtin加载与执行、字节码加载与调用等过程，详细讲解字节码解释执行过程，力求在演草纸上为读者描绘解释器的运行细节和字节码的解释过程。本文讲解思路是：利用汇编调试（debug），跟随JSFunction实例的执行，它执行到哪，就讲解到哪。本文内容组织方式：记录关键变量地址，做调试前的准备工作（章节2）；调试Bytecode解释执行过程（章节3）。  
+**注意：** 字节码处理程序（BytecodeHandler）是`CodeStubAssembler`类型的Builtin功能，debug分析只能看到汇编码，无C++代码。    
+![avatar](f1.png)  
+# 2 准备工作  
+测试用例是`console.log(JsPrint(6));`，它的Bytecode Array代码如下：  
+```c++
+162BD81556 @  0 : 12 00             LdaConstant [0]
+162BD81558 @  2 : 26 fa             Star r1
+162BD8155A @  4 : 0b                LdaZero
+162BD8155B @  5 : 26 f9             Star r2
+162BD8155D @  7 : 27 fe f8          Mov <closure>, r3
+162BD81560 @ 10 : 61 2d 01 fa 03    CallRuntime [DeclareGlobals], r1-r3
+162BD81565 @ 15 : a7                StackCheck
+162BD81566 @ 16 : 13 01 02          LdaGlobal [1], [2]
+162BD81569 @ 19 : 26 f9             Star r2
+162BD8156B @ 21 : 29 f9 02          LdaNamedPropertyNoFeedback r2, [2]
+162BD8156E @ 24 : 26 fa             Star r1
+162BD81570 @ 26 : 0d                LdaUndefined
+162BD81571 @ 27 : 26 f7             Star r4
+162BD81573 @ 29 : 13 03 00          LdaGlobal [3], [0]
+162BD81576 @ 32 : 26 f8             Star r3
+162BD81578 @ 34 : 0c 06             LdaSmi [6]
+162BD8157A @ 36 : 26 f6             Star r5
+162BD8157C @ 38 : 5f f8 f7 02       CallNoFeedback r3, r4-r5
+162BD81580 @ 42 : 26 f8             Star r3
+162BD81582 @ 44 : 5f fa f9 02       CallNoFeedback r1, r2-r3
+162BD81586 @ 48 : 26 fb             Star r0
+162BD81588 @ 50 : ab                Return
+```  
+汇编调试存在工作量大、晦涩难懂等诸多缺点，但它最大的优点是：能看到加载、解释、调度的细节，这是其它语言不具备的优势。开始汇编调试之前，要先看懂V8堆栈构建，字节码和寄存器编码规则等知识，它是本文必用的知识，参见第七篇。`Invoke()`是最后一个可以看到C++源码的函数，源码如下：  
+```c++
+1.  V8_WARN_UNUSED_RESULT MaybeHandle<Object> Invoke(Isolate* isolate,
+2.                                                  const InvokeParams& params) {
+3.   if (params.target->IsJSFunction()) {
+4.  //............省略很多...............
+5.   }
+6.    Object value;
+7.     Handle<Code> code =
+8.         JSEntry(isolate, params.execution_target, params.is_construct);
+9.     {
+10.       SaveContext save(isolate);
+11.       SealHandleScope shs(isolate);
+12.       if (FLAG_clear_exceptions_on_js_entry) isolate->clear_pending_exception();
+13.       if (params.execution_target == Execution::Target::kCallable) {
+14.         using JSEntryFunction = GeneratedCode<Address(
+15.             Address root_register_value, Address new_target, Address target,
+16.             Address receiver, intptr_t argc, Address** argv)>;
+17.         // clang-format on
+18.         JSEntryFunction stub_entry =
+19.             JSEntryFunction::FromAddress(isolate, code->InstructionStart());
+20.         Address orig_func = params.new_target->ptr();
+21.         Address func = params.target->ptr();
+22.         Address recv = params.receiver->ptr();
+23.         Address** argv = reinterpret_cast<Address**>(params.argv);
+24.         RuntimeCallTimerScope timer(isolate, RuntimeCallCounterId::kJS_Execution);
+25.         value = Object(stub_entry.Call(isolate->isolate_data()->isolate_root(),
+26.                                        orig_func, func, recv, params.argc, argv));
+27.       } else {
+28.  //............省略很多...............
+29.       }
+30.     }
+31.     //............省略很多...............
+32.     return Handle<Object>(value, isolate);
+33.   }
+```
+上述代码`Invoke()`为解释执行JSFunction实例做初始化工作，我们需要在此处记录JSFunction实例重要成员变量的地址：code、stub_entry、func，等等。以前的文章对这些变量知识做过讲解，本文不再赘述，直接给出结果：  
+（1）code，代码7行，它是Builtin:JSEntry的基址。
+地址：1FA 0E06 ED30  
+（2）stub_entry，代码18行，从code中计算Builtin:JSEntry中第一条指令地址，它是Ignition工作的入口地址。JSEntry的头部填充了其它信息，要利用堆栈偏移量取出正确数值，代码如下:  
+```c++
+Address Code::OffHeapInstructionStart() const {
+  DCHECK(is_off_heap_trampoline());
+  if (Isolate::CurrentEmbeddedBlob() == nullptr) return raw_instruction_start();
+  EmbeddedData d = EmbeddedData::FromBlob();
+  return d.InstructionStartOfBuiltin(builtin_index());
+}
+```  
+第一条指令地址：1FA 1326 1840    
+（3）func，代码21行，是JSFunction实例地址，它的Javascript源码是`console.log(JsPrint(6));`  
+地址：16 2BD8 15A9  
+（4）func中使用Builtin::InterpreterEntryTrampoline，地址：52 61C0 8A41   
+（5）dispatch_table，调度表基址：1FA 0E08 CFB0  
+以上信息用来在debug过程中对代码进行定位，图2给出当前位置函数调用堆栈，之后进入汇编debug。  
+![avatar](f2.png)  
+# 3 调试字节码  
+开始执行汇编，图3给出了`Invoke()`方法25行`stub_entry.Call()`的汇编代码和寄存器信息。  
+![avatar](f3.png)  
+RCX的值是stub_entry，是Builtin:JSEntry的第一条指令地址，code是Builtin:JSEntry的基址，RCX（stub_entry）是code中第一条指令地址。code加上偏移量得到的结果正是stub_entry，前面提到stub_entry是Ignition入口，接着执行见图4。  
+![avatar](f4.png)  
+RBX的值为1FA0E068A00，它是`Invoke()`方法25行`stub_entry.Call()`的第一个参数`isolate->isolate_data()->isolate_root()`。图4中能看到把RCX（stub_entry）存入rsp+58h，继续执行。  
+![avatar](f5.png)  
+图5中R8是func地址，`call rsi`这条指令时，RSI是stub_entry，执行Builtin:JSEntry，**Ignition开始执行。** 源码如下：  
+```c++
+1.  void Builtins::Generate_JSEntry(MacroAssembler* masm) {
+2.    Generate_JSEntryVariant(masm, StackFrame::ENTRY,
+3.                            Builtins::kJSEntryTrampoline);
+4.  }
+5.  //======================分隔线========================
+6.  void Generate_JSEntryVariant(MacroAssembler* masm, StackFrame::Type type,
+7.                               Builtins::Name entry_trampoline) {
+8.    Label invoke, handler_entry, exit;
+9.    Label not_outermost_js, not_outermost_js_2;
+10.    {  
+11.      NoRootArrayScope uninitialized_root_register(masm);
+12.      __ pushq(rbp);
+13.      __ movq(rbp, rsp);
+14.      __ Push(Immediate(StackFrame::TypeToMarker(type)));
+15.      __ AllocateStackSpace(kSystemPointerSize);
+16.      __ pushq(r12);
+17.      __ pushq(r13);
+18.      __ pushq(r14);
+19.      __ pushq(r15);
+20.  #ifdef _WIN64
+21.      __ pushq(rdi);  // Only callee save in Win64 ABI, argument in AMD64 ABI.
+22.      __ pushq(rsi);  // Only callee save in Win64 ABI, argument in AMD64 ABI.
+23.  #endif
+24.      __ pushq(rbx);
+25.  #ifdef _WIN64 //这个#ifdef为TRUE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+26.      // On Win64 XMM6-XMM15 are callee-save.
+27.      __ AllocateStackSpace(EntryFrameConstants::kXMMRegistersBlockSize);
+28.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 0), xmm6);
+29.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 1), xmm7);
+30.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 2), xmm8);
+31.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 3), xmm9);
+32.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 4), xmm10);
+33.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 5), xmm11);
+34.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 6), xmm12);
+35.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 7), xmm13);
+36.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 8), xmm14);
+37.      __ movdqu(Operand(rsp, EntryFrameConstants::kXMMRegisterSize * 9), xmm15);
+38.      STATIC_ASSERT(EntryFrameConstants::kCalleeSaveXMMRegisters == 10);
+39.      STATIC_ASSERT(EntryFrameConstants::kXMMRegistersBlockSize ==
+40.                    EntryFrameConstants::kXMMRegisterSize *
+41.                        EntryFrameConstants::kCalleeSaveXMMRegisters);
+42.  #endif
+43.  //............省略很多..............................
+44.  }
+```  
+上述代码12~37行，与图6中标记的汇编码完全对应，Builtin:JSEntry的功能是按标准C语言调用约定组织信息，为Builtin::InterpreterEntryTrampoline做准备。  
+![avatar](f6.png)  
+Builtin:JSEntry和Builtin::InterpreterEntryTrampoline源码请读者自行分析，不再赘述。Builtin::InterpreterEntryTrampoline源码中调用dispatch_table，进入测试用例的第一条字节码`LdaConstant`，图7给出加载dispatch_table，并计算和调用`LdaConstant`的过程。  
+![avatar](f7.png)  
+R15寄存器是dispatch_table基址，R15是V8维护的指令调度专用物理寄器，图7中（1）加载dispatch_table基址；（2）计算LdaConstant地址；（3）调用LdaConstant。  
+**总结：图7中，三个功能的组合，实现了指令调度，也就是每个字节码处理程序都有的尾部调用（TailCall）方法`Dispatch()`**  
+继续执行，进入`LdaConstant`的处理程序，代码如下：
+```c++
+1.  IGNITION_HANDLER(LdaConstant, InterpreterAssembler) {
+2.    TNode<Object> constant = LoadConstantPoolEntryAtOperandIndex(0);
+3.    SetAccumulator(constant);
+4.    Dispatch();
+5.  }
+```
+汇编码篇幅太长，字节码处理程序内部的汇编过程不做讲解，代码第4行`Dispatch();`调度下一条字节码`Star`，图8是调度的汇编码。  
+![avatar](f8.png)  
+图8中，R15依旧是dispatch_table基址，这正是V8官方文档中提到的:“用物理寄存器维护dispatch table”。  接下进入`Star`开始执行，剩余代码请读者自行分析。  
+  
+总结，本文从汇编角度对`console.log(JsPrint(6));`做了细致讲解，包括：Builtin::JSEntry、InterpreterEntryTrampoline的执行，字节码的加载（load）、解释（interpreter）以及调度（disaptch）四方面内容，描绘了Ignition从启动到解释字节码的全流程。    
+好了，今天到这里，下次见。   
+
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap18-1031/f1.png b/chap18-1031/f1.png
new file mode 100644
index 0000000..dc40acb
Binary files /dev/null and b/chap18-1031/f1.png differ
diff --git a/chap18-1031/f2.png b/chap18-1031/f2.png
new file mode 100644
index 0000000..44e7cc7
Binary files /dev/null and b/chap18-1031/f2.png differ
diff --git a/chap18-1031/f3.png b/chap18-1031/f3.png
new file mode 100644
index 0000000..70705ef
Binary files /dev/null and b/chap18-1031/f3.png differ
diff --git a/chap18-1031/f4.png b/chap18-1031/f4.png
new file mode 100644
index 0000000..b1e5e28
Binary files /dev/null and b/chap18-1031/f4.png differ
diff --git a/chap18-1031/f5.png b/chap18-1031/f5.png
new file mode 100644
index 0000000..fb9eb51
Binary files /dev/null and b/chap18-1031/f5.png differ
diff --git a/chap18-1031/f6.png b/chap18-1031/f6.png
new file mode 100644
index 0000000..614f825
Binary files /dev/null and b/chap18-1031/f6.png differ
diff --git a/chap18-1031/f7.png b/chap18-1031/f7.png
new file mode 100644
index 0000000..573a9a2
Binary files /dev/null and b/chap18-1031/f7.png differ
diff --git a/chap18-1031/f8.png b/chap18-1031/f8.png
new file mode 100644
index 0000000..d13fc3f
Binary files /dev/null and b/chap18-1031/f8.png differ
diff --git a/chap2-0914/Figure 1.png b/chap2-0914/Figure 1.png
new file mode 100644
index 0000000..45fb5dd
Binary files /dev/null and b/chap2-0914/Figure 1.png differ
diff --git a/chap2-0914/Figure 2.png b/chap2-0914/Figure 2.png
new file mode 100644
index 0000000..eaccc0e
Binary files /dev/null and b/chap2-0914/Figure 2.png differ
diff --git a/chap2-0914/Figure 3.png b/chap2-0914/Figure 3.png
new file mode 100644
index 0000000..2bd3dcd
Binary files /dev/null and b/chap2-0914/Figure 3.png differ
diff --git a/chap2-0914/Figure 4.png b/chap2-0914/Figure 4.png
new file mode 100644
index 0000000..fe001ad
Binary files /dev/null and b/chap2-0914/Figure 4.png differ
diff --git a/chap2-0914/Figure 5.png b/chap2-0914/Figure 5.png
new file mode 100644
index 0000000..94fbb1e
Binary files /dev/null and b/chap2-0914/Figure 5.png differ
diff --git a/chap2-0914/README.md b/chap2-0914/README.md
new file mode 100644
index 0000000..4a7ca85
--- /dev/null
+++ b/chap2-0914/README.md
@@ -0,0 +1,259 @@
+# 连载《Chrome V8 原理讲解》第二篇 鸟瞰V8运行过程，形成大局观
+![avatar](../v8.png)  
+
+# 本篇内容
+本次是第二篇，主要内容是从宏观上概述V8的运行过程，包括：初始化、编译代码、运行、退出。面对V8这个庞大的系统工程，本文尽力为读者构建一个全面的大局观，从程序源码的角度揭示V8代码的主要脉络，达到快速入手的目的。本文想给读者的“大局观”是：知道V8是怎么运行的，了解V8运行过程中的几个重要中间阶段、重要中间结果、以及相应的重要数据结构。为此，本文从Javascript代码的两个主要阶段编译和执行的知识点出发，以V8源码中的重要数据结构抽象语法树(AST)和字节表(Bytecode)为抓手展开全面、宏观的讲解。
+# 1 V8运行过程
+以v8\samples\hello-world.c为例，这个例子我曾反复说过，它是运行V8功能的最小代码集合，只包含了V8的最重要最基本的功能，适合入门。例如，徒增学习难度的优化编译功能，在这个例子中就没出现，优化编译是V8最重要的部分，是提升性能的关键，但对初学者并没有用，所以说只有基础功能的hello-world最适合入门。  
+```C++
+int main(int argc, char* argv[]) {
+  // Initialize V8.
+  v8::V8::InitializeICUDefaultLocation(argv[0]);
+  v8::V8::InitializeExternalStartupData(argv[0]);
+  std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
+  v8::V8::InitializePlatform(platform.get());
+  v8::V8::Initialize();
+
+  // Create a new Isolate and make it the current one.
+  v8::Isolate::CreateParams create_params;
+  create_params.array_buffer_allocator =
+      v8::ArrayBuffer::Allocator::NewDefaultAllocator();
+  v8::Isolate* isolate = v8::Isolate::New(create_params);
+  {
+    v8::Isolate::Scope isolate_scope(isolate);
+
+    // Create a stack-allocated handle scope.
+    v8::HandleScope handle_scope(isolate);
+
+    // Create a new context.
+    v8::Local<v8::Context> context = v8::Context::New(isolate);
+
+    // Enter the context for compiling and running the hello world script.
+    v8::Context::Scope context_scope(context);
+
+    {
+      // Create a string containing the JavaScript source code.
+      v8::Local<v8::String> source =
+          v8::String::NewFromUtf8Literal(isolate, "'Hello' + ', World!'");
+
+      // Compile the source code.
+      v8::Local<v8::Script> script =
+          v8::Script::Compile(context, source).ToLocalChecked();
+
+      // Run the script to get the result.
+      v8::Local<v8::Value> result = script->Run(context).ToLocalChecked();
+//...      
+//省略部分代码
+//...
+```  
+上面这段代码是hello-world.cc中最重要的部分，V8的初始化是v8::V8::Initialize()，Isolate的创建v8::Isolate::New，编译v8::Script::Compile，执行script->Run。handle和context没有提及，因为对初学者不重要。图1说明了每个阶段的重要数据结构，读者可以利用VS2019的debug跟踪查看详细过程（跟踪方法见上一篇文章）。  
+![avatar](Figure%201.png)  
+图1中可以看到hello-world.cc程序的主要主体结构（工作流程），还有与之对应的方法和数据结构。V8代码量很大，通过重要数据结构和中间结果入手学习，可以很好地抓住V8的主线功能，把主线功能理解透彻之后，再学习旁支功能可达到事半功倍的效果。接下来，以图1中主要方法为主，结合主要数据结构进行单独讲解。   
+# 2 V8启动时的内存申请  
+InitReservation负责为V8申请内存，代码位置src\utils\allocation.cc。
+```C++
+// Reserve a region of twice the size so that there is an aligned address
+// within it that's usable as the cage base.
+VirtualMemory padded_reservation(params.page_allocator,
+                               params.reservation_size * 2,
+                               reinterpret_cast<void*>(hint));
+Address address =
+          VirtualMemoryCageStart(padded_reservation.address(), params);
+...省略了很多行代码...
+// Now free the padded reservation and immediately try to reserve an
+// exact region at aligned address. We have to do this dancing because
+// the reservation address requirement is more complex than just a
+// certain alignment and not all operating systems support freeing parts
+// of reserved address space regions.
+padded_reservation.Free();
+VirtualMemory reservation(params.page_allocator,
+                          params.reservation_size,
+                          reinterpret_cast<void*>(address));
+```
+申请内存时为了保证内存对齐，它的做法是先申请两倍的内存,然后从中找一个适合做内存对齐的地址，再把两倍内存释放，从刚找到的地址申请需要的4G大小。具体做法是：padded_reservation申请一个两倍大小的内存（8G）,再利用padded_reservation.Free()释放，再用reservation申请的4G内存则是V8真正的内存。下面讲解V8管理内存的主要数据结构：VirtualMemoryCage。V8向操作系统申请4G内存，用于后续的所有工作，例如创新Isolate，等等。V8的内存方式采用的段页式，和操作系统（OS）的方法类似，但不像OS有多个段，V8只有一个段，但有很多页。VirtualMemeoryCage的定义在allocation.h中，我们对它的结构进行说明。  
+```
+// +------------+-----------+-----------  ~~~  -+
+// |     ...    |    ...    |   ...             |
+// +------------+-----------+------------ ~~~  -+
+// ^            ^           ^
+// start        cage base   allocatable base
+//
+// <------------>           <------------------->
+// base bias size              allocatable size
+// <-------------------------------------------->
+//             reservation size
+```
+"a VirtualMemory reservation"是V8源码中的叫法，reservation size是4G，也就是v8申请内存的总大小，start是这个内存的基址，cage base是v8用于管理的基址，可以先理解为cage base是页表位置，allocatable开始是v8可以分配的，用于创新isolate。VirtualMemoryCage中的成员reservation_负责指向这个4G内存。另一个重要的结构是ReservationParams,申请内存大小(4G),对齐方式，指针压缩等参数都在这个结构中定义。 
+# 3 Isolate
+Isolate是一个完整的V8实例，有着完整的堆栈和Heap。V8是虚拟机，isolate才是运行javascript的宿主。一个Isolate是一个独立的运行环境, 包括但不限于堆管理器(heap)、垃圾回收器（gc）等。在一个时间，有且只有一个线程能在isolate中运行代码，也就是说同一时刻，只有一个线程能进入isolate,多个线程可以通过切换来共享同一个isolate。  
+```C++
+/**
+ * Isolate represents an isolated instance of the V8 engine.  V8 isolates have
+ * completely separate states.  Objects from one isolate must not be used in
+ * other isolates.  The embedder can create multiple isolates and use them in
+ * parallel in multiple threads.  An isolate can be entered by at most one
+ * thread at any given time.  The Locker/Unlocker API must be used to
+ * synchronize.
+ */
+class V8_EXPORT Isolate {
+ public:
+  /**
+   * Initial configuration parameters for a new Isolate.
+   */
+  struct V8_EXPORT CreateParams {
+    CreateParams();
+    ~CreateParams();
+
+    /**
+     * Allows the host application to provide the address of a function that is
+     * notified each time code is added, moved or removed.
+     */
+    JitCodeEventHandler code_event_handler = nullptr;
+
+    /**
+     * ResourceConstraints to use for the new Isolate.
+     */
+    ResourceConstraints constraints;
+
+    /**
+     * Explicitly specify a startup snapshot blob. The embedder owns the blob.
+     */
+    StartupData* snapshot_blob = nullptr;
+
+    /**
+     * Enables the host application to provide a mechanism for recording
+     * statistics counters.
+     */
+    CounterLookupCallback counter_lookup_callback = nullptr;
+//.....
+//省略多行
+//.....
+```
+上面这段代码是isolate对外(export)提供的接口，方便其它程序的使用。 这个isolate可以理解为javascript的运行单元，多个线程也就是多个任务可以共享一个运行单元，这种共享类似操作系统中的调度机制，涉及到几个重要的概念：任务切换（亦称任务调度）、中断、上下文(context)的切换方法，由此我们引出V8中几个重要的概念。  
+**a**.Context：上下文，所有的JS代码都是在某个V8 Context中运行的。
+**b**.Handle，一个指定JS对象的索引，它指向此JS对象在V8堆中的位置。
+**c**.Handle Scope，包含很多handle的集合，用于对多个handle进行统一管理,当Scope被移出堆时，它所管理的handle集合也就被释放了。  
+
+其它的重要概念，本文不涉及，暂不深究。
+Isolate还有一个对内的isolate数据结构,代码如下。它可以与对外接口进行无差别转换，在转换过程中，数据不会丢失。  
+```C++
+class V8_EXPORT_PRIVATE Isolate final : private HiddenFactory {
+  // These forward declarations are required to make the friend declarations in
+  // PerIsolateThreadData work on some older versions of gcc.
+  class ThreadDataTable;
+  class EntryStackItem;
+
+ public:
+  Isolate(const Isolate&) = delete;
+  Isolate& operator=(const Isolate&) = delete;
+
+  using HandleScopeType = HandleScope;
+  void* operator new(size_t) = delete;
+  void operator delete(void*) = delete;
+
+  // A thread has a PerIsolateThreadData instance for each isolate that it has
+  // entered. That instance is allocated when the isolate is initially entered
+  // and reused on subsequent entries.
+  class PerIsolateThreadData {
+   public:
+    PerIsolateThreadData(Isolate* isolate, ThreadId thread_id)
+        : isolate_(isolate),
+          thread_id_(thread_id),
+          stack_limit_(0),
+          thread_state_(nullptr)
+//省略很多代码...
+```  
+这个isolate是V8内部使用的，不对外开放。这个结构贯穿了V8虚拟机的始终，是我们必须要掌握的，从入门的角度来讲，这个结构不是我们最先需要掌握的，我们只需要知道它，用到相关的成员再来查找，下文讲解的几个重要结构，其实都是i::isolate的成员。
+# 3 编译  
+编译涉及到的概念包括：词法分析，用来生成token字；语法分析(parse)，最后生成抽象语法树（AST）。下面介绍重要的数据结构
+```C++
+// A container for the inputs, configuration options, and outputs of parsing.
+class V8_EXPORT_PRIVATE ParseInfo {
+ public:
+  ParseInfo(Isolate* isolate, const UnoptimizedCompileFlags flags,
+            UnoptimizedCompileState* state);
+
+  // Creates a new parse info based on parent top-level |outer_parse_info| for
+  // function |literal|.
+  static std::unique_ptr<ParseInfo> ForToplevelFunction(
+      const UnoptimizedCompileFlags flags,
+      UnoptimizedCompileState* compile_state, const FunctionLiteral* literal,
+      const AstRawString* function_name);
+
+  ~ParseInfo();
+
+  template <typename IsolateT>
+  EXPORT_TEMPLATE_DECLARE(V8_EXPORT_PRIVATE)
+  Handle<Script> CreateScript(IsolateT* isolate, Handle<String> source,
+                              MaybeHandle<FixedArray> maybe_wrapped_arguments,
+                              ScriptOriginOptions origin_options,
+                              NativesFlag natives = NOT_NATIVES_CODE);
+
+  // Either returns the ast-value-factory associcated with this ParseInfo, or
+  // creates and returns a new factory if none exists.
+  AstValueFactory* GetOrCreateAstValueFactory();
+  ```
+  这个结构的作用是接收javascript源码（U16格式），输出就是AST，在它输出AST过程中，会临时生成Token，AST生成后销毁，不做永久保存，生成token过程中还用到了缓存(cache)机制来提高效率。下面先来看一段JS的AST语法树，如图2。
+  ![avatar](Figure%202.png)  
+  图2左侧是js源码，右侧是通过VS2019的调试工具看到的AST树，借助d8工具也能打印AST树，如图3所示，一屏显示不全，只截取了部分。  
+  ![avatar](Figure%203.png)  
+  下面是AST树的主要数据结构。
+  ```c++
+class FunctionLiteral final : public Expression {
+ public:
+  enum ParameterFlag : uint8_t {
+    kNoDuplicateParameters,
+    kHasDuplicateParameters
+  };
+  enum EagerCompileHint : uint8_t { kShouldEagerCompile, kShouldLazyCompile };
+
+  // Empty handle means that the function does not have a shared name (i.e.
+  // the name will be set dynamically after creation of the function closure).
+  template <typename IsolateT>
+  MaybeHandle<String> GetName(IsolateT* isolate) const {
+    return raw_name_ ? raw_name_->AllocateFlat(isolate) : MaybeHandle<String>();
+  }
+  bool has_shared_name() const { return raw_name_ != nullptr; }
+  const AstConsString* raw_name() const { return raw_name_; }
+  void set_raw_name(const AstConsString* name) { raw_name_ = name; }
+  DeclarationScope* scope() const { return scope_; }
+  ZonePtrList<Statement>* body() { return &body_; }
+  void set_function_token_position(int pos) { function_token_position_ = pos; }
+  int function_token_position() const { return function_token_position_; }
+  int start_position() const;
+  int end_position() const;
+  bool is_anonymous_expression() const {
+    return syntax_kind() == FunctionSyntaxKind::kAnonymousExpression;
+  }
+  //省略很多代码... ...
+  ```    
+  Abstract Syntax Tree抽象语法树（AST）是精简版的解析树(parse tree)，在编译过程中，解析树是包含javascript源码所有语法信息的树型表示结构，它是代码在编译阶段的等价表示。抽象语法树概念是相对于解析树而言，对解析树进行裁剪，去掉一些语法信息和一些不重要的细节，所以叫抽象语法树。  
+  V8编译的第一个阶段是扫描(scanner)js源代码文本，把文本拆成一些单词,再传入分词器，经过一系列的类型识别，根据词的类型识别单词的含义，进而产生token序列，单词识别过程有一个预先定义好的识别器类型模板，如图4。    
+  ![avatar](Figure%204.png)  
+  图4中只截取了部分，读者可根据文件名自行查阅。  
+  # 4 代码执行  
+  图5中给出来了执行Javascript代码的关键位置，从此处debug跟踪，将最终进入字节码(bytecode)的执行过程。  
+  ![avatar](Figure%205.png) 
+  下面来看Exectuion这个数据结构，这个结构承载着运行过程前后的相关信息。
+  ```c++
+  class Execution final : public AllStatic {
+ public:
+  // Whether to report pending messages, or keep them pending on the isolate.
+  enum class MessageHandling { kReport, kKeepPending };
+  enum class Target { kCallable, kRunMicrotasks };
+
+  // Call a function, the caller supplies a receiver and an array
+  // of arguments.
+  //
+  // When the function called is not in strict mode, receiver is
+  // converted to an object.
+  //
+  V8_EXPORT_PRIVATE V8_WARN_UNUSED_RESULT static MaybeHandle<Object> Call(
+      Isolate* isolate, Handle<Object> callable, Handle<Object> receiver,
+      int argc, Handle<Object> argv[]);
+  //省略很多
+  ```
+  从图5中标记的位置跟踪进入能看到执行的细节，目前我们还没提到AST如何生成字节码，但已基本梳理了v8从启动到运行的关建过程，和关键的数据结构。我们已经能看到Javascript源码对应的AST树是什么样子，它在执行期时的字节码又是什么样。
+  好了，今天到这里，下次见。  
+
+**微信：qq9123013  备注：v8交流学习    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap3-0915/README.md b/chap3-0915/README.md
new file mode 100644
index 0000000..09eb0c8
--- /dev/null
+++ b/chap3-0915/README.md
@@ -0,0 +1,355 @@
+# 连载《Chrome V8 原理讲解》第三篇 看V8编译流程，学习词法分析
+
+
+![avatar](../v8.png)  
+# 本篇内容
+本次是第三篇，讲解V8中词法分析（scanner）的实现，这中间涉及到几个重要的数据结构和一些相关的编译知识，本文也尽量全面讲解相关的编译知识，争取让读者有一个全面的认识。**注：本文不涉及V8的优化编译**
+# 1.V8编译流程
+总体来说，V8的编译过程是同步实现的，主体流程是扫描在初始化时先生成一个token字，并放入缓存（cache），然后开始分析（parser），从缓存中取一个token做分析，然后生成抽象语法树的一个节点，再取下一个token进行分析，如此循环。如果缓存未命中(cache miss),便启动扫描去生成token，如图1所示。  
+![avatar](f1.png)  
+下面看一下V8中的代码实现，Parser::ParseProgram方法，是图1中扫描器(scanner)的入口点。在这段代码中可以看到scanner_.Initialize()和FunctionLiteral* result = DoParseProgram(isolate, info)，这两个方法的作用是：  
+**1.初始化扫描器(scanner)：** 生成第一个token字，scanner.c0_指向第一个开始的字符，也就是要扫描的第一个字符。  
+**2.DoParseProgram(isolate, info)：** 读取token字，生成AST的body，最终所有body汇聚成AST语法树。  
+```c++
+void Parser::ParseProgram(Isolate* isolate, Handle<Script> script,
+                          ParseInfo* info,
+                          MaybeHandle<ScopeInfo> maybe_outer_scope_info) {
+  DCHECK_EQ(script->id(), flags().script_id());
+
+  // It's OK to use the Isolate & counters here, since this function is only
+  // called in the main thread.
+  DCHECK(parsing_on_main_thread_);
+  RCS_SCOPE(runtime_call_stats_, flags().is_eval()
+                                     ? RuntimeCallCounterId::kParseEval
+                                     : RuntimeCallCounterId::kParseProgram);
+  TRACE_EVENT0(TRACE_DISABLED_BY_DEFAULT("v8.compile"), "V8.ParseProgram");
+  base::ElapsedTimer timer;
+  if (V8_UNLIKELY(FLAG_log_function_events)) timer.Start();
+
+  // Initialize parser state.
+  DeserializeScopeChain(isolate, info, maybe_outer_scope_info,
+                        Scope::DeserializationMode::kIncludingVariables);
+
+  DCHECK_EQ(script->is_wrapped(), info->is_wrapped_as_function());
+  if (script->is_wrapped()) {
+    maybe_wrapped_arguments_ = handle(script->wrapped_arguments(), isolate);
+  }
+
+  scanner_.Initialize();
+  FunctionLiteral* result = DoParseProgram(isolate, info);
+  MaybeResetCharacterStream(info, result);
+  MaybeProcessSourceRanges(info, result, stack_limit_);
+  PostProcessParseResult(isolate, info, result);
+
+  HandleSourceURLComments(isolate, script);
+
+  if (V8_UNLIKELY(FLAG_log_function_events) && result != nullptr) {
+    double ms = timer.Elapsed().InMillisecondsF();
+    const char* event_name = "parse-eval";
+    int start = -1;
+    int end = -1;
+    if (!flags().is_eval()) {
+      event_name = "parse-script";
+      start = 0;
+      end = String::cast(script->source()).length();
+    }
+    LOG(isolate,
+        FunctionEvent(event_name, flags().script_id(), ms, start, end, "", 0));
+  }
+}
+```
+上述这段代码（Parser::ParseProgram）是分析V8中编译代码的最近入口点，从此处进入跟踪，可以看到编译的全流程。这个方法的外层也有很多调用者（caller）,但这些调用者的任务仅仅是做准备工作，这个方法开始进入了真正的编译，尤其要注意，在scanner的初始化阶段（scanner_.Initialize）就已经开始做了第一次扫描。  
+# 2.V8词法分析(scanner)工作流程 
+编译器的第一个步骤称为词法分析（lexical analysis）或扫描（scanning），在编译原理这门课程中，我的老师用“词法分析”这个名词，当我看编译器源码，面对工程实现时，看到是“扫描”这个名词，这两种叫法一个是注重原理，另一个是注重实现。词法分析器读入源程序的字符流，并且将他们组织成为有意义的词素（lexeme）的序列，再生成相应的词法单元(token)。  
+在V8中，源程序的字符流是UTF-16编码，存储字符流的数据结构如下：  
+```c++
+// ---------------------------------------------------------------------
+// Buffered stream of UTF-16 code units, using an internal UTF-16 buffer.
+// A code unit is a 16 bit value representing either a 16 bit code point
+// or one part of a surrogate pair that make a single 21 bit code point.
+class Utf16CharacterStream {
+ public:
+  static constexpr base::uc32 kEndOfInput = static_cast<base::uc32>(-1);
+
+  virtual ~Utf16CharacterStream() = default;
+
+  V8_INLINE void set_parser_error() {
+    buffer_cursor_ = buffer_end_;
+    has_parser_error_ = true;
+  }
+  V8_INLINE void reset_parser_error_flag() { has_parser_error_ = false; }
+  V8_INLINE bool has_parser_error() const { return has_parser_error_; }
+
+  inline base::uc32 Peek() {
+    if (V8_LIKELY(buffer_cursor_ < buffer_end_)) {
+      return static_cast<base::uc32>(*buffer_cursor_);
+    } else if (ReadBlockChecked()) {
+      return static_cast<base::uc32>(*buffer_cursor_);
+    } else {
+      return kEndOfInput;
+    }
+  }
+
+  // Returns and advances past the next UTF-16 code unit in the input
+  // stream. If there are no more code units it returns kEndOfInput.
+  inline base::uc32 Advance() {
+    base::uc32 result = Peek();
+    buffer_cursor_++;
+    return result;
+  }
+
+//...............
+//中间省略很多代码.....
+//..............
+
+
+
+  // Read more data, and update buffer_*_ to point to it.
+  // Returns true if more data was available.
+  //
+  // ReadBlock() may modify any of the buffer_*_ members, but must sure that
+  // the result of pos() remains unaffected.
+  //
+  // Examples:
+  // - a stream could either fill a separate buffer. Then buffer_start_ and
+  //   buffer_cursor_ would point to the beginning of the buffer, and
+  //   buffer_pos would be the old pos().
+  // - a stream with existing buffer chunks would set buffer_start_ and
+  //   buffer_end_ to cover the full chunk, and then buffer_cursor_ would
+  //   point into the middle of the buffer, while buffer_pos_ would describe
+  //   the start of the buffer.
+  virtual bool ReadBlock() = 0;
+
+  const uint16_t* buffer_start_;
+  const uint16_t* buffer_cursor_;
+  const uint16_t* buffer_end_;
+  size_t buffer_pos_;
+  RuntimeCallStats* runtime_call_stats_;
+  bool has_parser_error_ = false;
+};
+```
+上述代码中，省略了很多中间代码，我保留最开始的英文注释和最后几个重要成员的英文注释，这几个重要的成员分别是buffer_start_，buffer_cursor_，buffer_end_，它们的作用是用来记录源码流，详细见代码中的注释。下面通过一个示例来看下class Utf16CharacterStream的应用场景。  
+![avatar](f2.png)  
+图2中左侧是js源代码，右侧是源码被读进内存，准备编译，通过下面的代码移交给buffer_start_进行管理。  
+```c++
+  bool ReadBlock() final {
+    size_t position = pos();
+    buffer_pos_ = position;
+    buffer_start_ = &buffer_[0];
+    buffer_cursor_ = buffer_start_;
+
+    DisallowGarbageCollection no_gc;
+    Range<uint8_t> range =
+        byte_stream_.GetDataAt(position, runtime_call_stats(), &no_gc);
+    if (range.length() == 0) {
+      buffer_end_ = buffer_start_;
+      return false;
+    }
+
+    size_t length = std::min({kBufferSize, range.length()});
+    i::CopyChars(buffer_, range.start, length);
+    buffer_end_ = &buffer_[length];
+    return true;
+  }
+```
+代码的buffer_start_ = &buffer_[0]，这一句是用buffer_start_指向待编译源码的第一个字符。图3给出的是Utf16CharacterStream类中重要的函数。这个函数是读取一个块代码(code unit)，是后续生成token时的输入字符串。  
+![avatar](f3.png)  
+前面提到的scanner.c0_这个成员，始终是指向即将开始token生成的字符串，下面的代码也说明了c0_的作用。
+```C++
+  void Advance() {
+    if (capture_raw) {
+      AddRawLiteralChar(c0_);
+    }
+    c0_ = source_->Advance();//看这里
+  }
+```
+在scanner初始化的最后一步调用了下面这个方法，生成一个token。  
+```C++
+void Scanner::Scan(TokenDesc* next_desc) {
+  DCHECK_EQ(next_desc, &next());
+
+  next_desc->token = ScanSingleToken();
+  DCHECK_IMPLIES(has_parser_error(), next_desc->token == Token::ILLEGAL);
+  next_desc->location.end_pos = source_pos();
+
+#ifdef DEBUG
+  SanityCheckTokenDesc(current());
+  SanityCheckTokenDesc(next());
+  SanityCheckTokenDesc(next_next());
+#endif
+}
+```  
+我们可以看到next_desc->token = ScanSingleToken()这句代码就是在生成一个token，可以看到next_desc是描述token字的关键结构，他是在Scanner中定义的一个结构体，代码如下：  
+```c++
+  struct TokenDesc {
+    Location location = {0, 0};
+    LiteralBuffer literal_chars;
+    LiteralBuffer raw_literal_chars;
+    Token::Value token = Token::UNINITIALIZED;
+    MessageTemplate invalid_template_escape_message = MessageTemplate::kNone;
+    Location invalid_template_escape_location;
+    uint32_t smi_value_ = 0;
+    bool after_line_terminator = false;
+
+#ifdef DEBUG
+    bool CanAccessLiteral() const {
+      return token == Token::PRIVATE_NAME || token == Token::ILLEGAL ||
+             token == Token::ESCAPED_KEYWORD || token == Token::UNINITIALIZED ||
+             token == Token::REGEXP_LITERAL ||
+             base::IsInRange(token, Token::NUMBER, Token::STRING) ||
+             Token::IsAnyIdentifier(token) || Token::IsKeyword(token) ||
+             base::IsInRange(token, Token::TEMPLATE_SPAN, Token::TEMPLATE_TAIL);
+    }
+    bool CanAccessRawLiteral() const {
+      return token == Token::ILLEGAL || token == Token::UNINITIALIZED ||
+             base::IsInRange(token, Token::TEMPLATE_SPAN, Token::TEMPLATE_TAIL);
+    }
+#endif  // DEBUG
+  };
+```
+到此，词法分析的初始化完了，后面由Parse驱动它进行工作，词法分析工作的入口点如下。  
+```C++
+void Scanner::Scan(TokenDesc* next_desc) {
+  DCHECK_EQ(next_desc, &next());
+
+  next_desc->token = ScanSingleToken();
+  DCHECK_IMPLIES(has_parser_error(), next_desc->token == Token::ILLEGAL);
+  next_desc->location.end_pos = source_pos();
+
+#ifdef DEBUG
+  SanityCheckTokenDesc(current());
+  SanityCheckTokenDesc(next());
+  SanityCheckTokenDesc(next_next());
+#endif
+}
+```
+# 3.V8词法分析的知识点
+编译技术是一个庞大的知识领域，涉及很多方面的理论知识，一个编译器的具体实现主要包括：词法分析、语义分析、中间代码、机器无关代码，机器码等多个阶段，此外，还有各种优化技术，例如：控制流优化、数据流优化、寄存器优化等等，这些优化技术与这些阶段交错执行，最终生成目标程序。从编译技术的角度看，V8的编译的每段代码都有相对应的理论支撑，看懂了这些理论，再来看V8编译源码，会很容易的。我们来看一下V8词法分析的知识点。
+词法分析是编译的第一个阶段。词法分析器的主要任务是读入源程序的输入字符、将它他们组成词素（lexeme），生成并输出一个词法单元（token），每个词法单元对应一个词素，这个词法单元被输出到语法分析器进行语法分析。当词法分析器发现一个标识符时，还会利用符号表进行保存。词法分析的工作流程、与符号表的交互过程都是由语法分析器驱动，如图4。  
+![avatar](f4.png)  
+图4中，getNextToken是驱动词法分析器工作,向其索取token的命令,直到它识别出下一个词素为止，然后将生成的token返回给语法分析器。看一下V8的这个过程的实现方法。  
+```C++
+void ParserBase<Impl>::ParseStatementList(StatementListT* body,
+                                          Token::Value end_token) {
+  // StatementList ::
+  //   (StatementListItem)* <end_token>
+  DCHECK_NOT_NULL(body);
+
+  while (peek() == Token::STRING) {
+    bool use_strict = false;
+#if V8_ENABLE_WEBASSEMBLY
+    bool use_asm = false;
+#endif  // V8_ENABLE_WEBASSEMBLY
+
+    Scanner::Location token_loc = scanner()->peek_location();
+
+    if (scanner()->NextLiteralExactlyEquals("use strict")) {
+      use_strict = true;
+#if V8_ENABLE_WEBASSEMBLY
+    } else if (scanner()->NextLiteralExactlyEquals("use asm")) {
+      use_asm = true;
+#endif  // V8_ENABLE_WEBASSEMBLY
+    }
+
+    StatementT stat = ParseStatementListItem();
+//.......................
+//省略很多....
+//.......................
+  }
+
+  while (peek() != end_token) {
+    StatementT stat = ParseStatementListItem();
+    if (impl()->IsNull(stat)) return;
+    if (stat->IsEmptyStatement()) continue;
+    body->Add(stat);
+  }
+}
+```
+这段代码很长，而且我们在调式过程中，由于选取的调试用例不同，不一定能覆盖到每一条语句。我们只看最后的一部分,我的调试代码触发了最后这个while()的执行，其中最重要是 ParseStatementListItem()，图5给出了Parse驱动SCanner的调用堆栈，堆栈中的函数调用流程，也就是图4中的getNextToken的具体实现。  
+![avatar](f5.png)  
+在图5中还能看到前面(图1)提到的缓存(cache)，它在v8中的实现是Consum方法。下面给出V8中Token生成的详细实现。
+```c++
+V8_INLINE Token::Value Scanner::ScanSingleToken() {
+  Token::Value token;
+  do {
+    next().location.beg_pos = source_pos();
+
+    if (V8_LIKELY(static_cast<unsigned>(c0_) <= kMaxAscii)) {
+      token = one_char_tokens[c0_];
+
+      switch (token) {
+//..............
+//代码太长，省略很多
+//..............
+
+        case Token::CONDITIONAL:
+          // ? ?. ?? ??=
+          Advance();
+          if (c0_ == '.') {
+            Advance();
+            if (!IsDecimalDigit(c0_)) return Token::QUESTION_PERIOD;
+            PushBack('.');
+          } else if (c0_ == '?') {
+            return Select('=', Token::ASSIGN_NULLISH, Token::NULLISH);
+          }
+          return Token::CONDITIONAL;
+
+        case Token::STRING:
+          return ScanString();
+
+        case Token::LT:
+          // < <= << <<= <!--
+          Advance();
+          if (c0_ == '=') return Select(Token::LTE);
+          if (c0_ == '<') return Select('=', Token::ASSIGN_SHL, Token::SHL);
+          if (c0_ == '!') {
+            token = ScanHtmlComment();
+            continue;
+          }
+          return Token::LT;
+        case Token::ASSIGN:
+          // = == === =>
+          Advance();
+          if (c0_ == '=') return Select('=', Token::EQ_STRICT, Token::EQ);
+          if (c0_ == '>') return Select(Token::ARROW);
+          return Token::ASSIGN;
+
+        case Token::NOT:
+          // ! != !==
+          Advance();
+          if (c0_ == '=') return Select('=', Token::NE_STRICT, Token::NE);
+          return Token::NOT;
+
+        case Token::ADD:
+          // + ++ +=
+          Advance();
+          if (c0_ == '+') return Select(Token::INC);
+          if (c0_ == '=') return Select(Token::ASSIGN_ADD);
+          return Token::ADD;
+//..............
+//代码太长，省略很多
+//..............
+
+        default:
+          UNREACHABLE();
+      }
+    }
+
+    if (IsIdentifierStart(c0_) ||
+        (CombineSurrogatePair() && IsIdentifierStart(c0_))) {
+      return ScanIdentifierOrKeyword();
+    }
+    if (c0_ == kEndOfInput) {
+      return source_->has_parser_error() ? Token::ILLEGAL : Token::EOS;
+    }
+    token = SkipWhiteSpace();
+
+    // Continue scanning for tokens as long as we're just skipping whitespace.
+  } while (token == Token::WHITESPACE);
+
+  return token;
+}
+```
+从代码中可以看出，生成token的过程就是这个switch case，它是一个自动机，token生成的过程也大量用到了正则表达。总结一句：token的生成过程就是字符匹配的过程，在V8中预先定义了token模板（TOKEN_LIST），再利用switch case完成字符匹配，生成token。
+好了，今天到这里，下次见。  
+**微信：qq9123013  备注：v8交流学习    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap3-0915/f1.png b/chap3-0915/f1.png
new file mode 100644
index 0000000..7d664d5
Binary files /dev/null and b/chap3-0915/f1.png differ
diff --git a/chap3-0915/f2.png b/chap3-0915/f2.png
new file mode 100644
index 0000000..267f7a9
Binary files /dev/null and b/chap3-0915/f2.png differ
diff --git a/chap3-0915/f3.png b/chap3-0915/f3.png
new file mode 100644
index 0000000..c06d2cb
Binary files /dev/null and b/chap3-0915/f3.png differ
diff --git a/chap3-0915/f4.png b/chap3-0915/f4.png
new file mode 100644
index 0000000..87eec3a
Binary files /dev/null and b/chap3-0915/f4.png differ
diff --git a/chap3-0915/f5.png b/chap3-0915/f5.png
new file mode 100644
index 0000000..34bef91
Binary files /dev/null and b/chap3-0915/f5.png differ
diff --git a/chap4-0917/README.md b/chap4-0917/README.md
new file mode 100644
index 0000000..d1644c3
--- /dev/null
+++ b/chap4-0917/README.md
@@ -0,0 +1,347 @@
+# 连载《Chrome V8 原理讲解》第四篇 V8词法分析源码讲解，Token字生成
+
+![avatar](../v8.png)  
+# 本篇内容
+本次是第四篇，以“测试样例代码”为V8的输入，跟随样例代码在词法分析(scanner)阶段的处理过程,剖析V8词法分析的源码实现。本文通过讲解样例代码中前两个token字（`function`、`JsPrint`）的生成过程，将V8词法分析的核心源码、主要工作流程以及重要数据结构呈现给大家。
+
+# 测试样例代码
+**注意：** 测试代码语法简单，因此不会覆盖词法分析的全部流程。token字的生成过程是自动机，由`switch case`实现，“不能全覆盖”是指测试代码不会触发所有的case条件，但这不会影响我们的学习，原理详见上一篇文章。
+```Javascript
+function JsPrint(a){
+	if(a >5){
+		return "Debug";
+	}
+}
+console.log(JsPrint(6));
+```
+# 词法分析概述
+谈及词法分析时，有三个重要的术语需要知道，词法单元（token）、模式描述（pattern）、词素（lexeme）。词法分析的工作流程是先找到一个词法单元，再找这个词法单元的所有的可选属性--模式描述和词素的组合，循环往复去找下一个词法单元，详细说明见上一篇文章。
+# 1.扫描词法单元`function`和`JsPrint`
+V8_INLINE Token::Value Scanner::ScanSingleToken()，这个方法是扫描token字的入口。`c0_`在初始化阶段已经指向了源代码的第一个字符(初始化流程，见上篇文章)，在本文的样例代码中，它代表“f”。
+```c++
+V8_INLINE Token::Value Scanner::ScanSingleToken() {
+  Token::Value token;
+  do {
+    next().location.beg_pos = source_pos();
+
+    if (V8_LIKELY(static_cast<unsigned>(c0_) <= kMaxAscii)) {
+      token = one_char_tokens[c0_];
+
+      switch (token) {
+        case Token::LPAREN:
+        case Token::RPAREN:
+        case Token::LBRACE:
+        case Token::RBRACE:
+        case Token::LBRACK:
+        case Token::RBRACK:
+        case Token::COLON:
+        case Token::SEMICOLON:
+        case Token::COMMA:
+        case Token::BIT_NOT:
+        case Token::ILLEGAL:
+          // One character tokens.
+          return Select(token);
+
+        case Token::CONDITIONAL:
+          // ? ?. ?? ??=
+          Advance();
+          if (c0_ == '.') {
+            Advance();
+            if (!IsDecimalDigit(c0_)) return Token::QUESTION_PERIOD;
+            PushBack('.');
+          } else if (c0_ == '?') {
+            return Select('=', Token::ASSIGN_NULLISH, Token::NULLISH);
+          }
+          return Token::CONDITIONAL;
+
+        case Token::STRING:
+          return ScanString();
+
+        case Token::LT:
+          // < <= << <<= <!--
+          Advance();
+          if (c0_ == '=') return Select(Token::LTE);
+          if (c0_ == '<') return Select('=', Token::ASSIGN_SHL, Token::SHL);
+          if (c0_ == '!') {
+            token = ScanHtmlComment();
+            continue;
+          }
+          return Token::LT;
+
+        case Token::GT:
+          // > >= >> >>= >>> >>>=
+          Advance();
+          if (c0_ == '=') return Select(Token::GTE);
+          if (c0_ == '>') {
+            // >> >>= >>> >>>=
+            Advance();
+            if (c0_ == '=') return Select(Token::ASSIGN_SAR);
+            if (c0_ == '>') return Select('=', Token::ASSIGN_SHR, Token::SHR);
+            return Token::SAR;
+          }
+          return Token::GT;
+
+        case Token::ASSIGN:
+          // = == === =>
+          Advance();
+          if (c0_ == '=') return Select('=', Token::EQ_STRICT, Token::EQ);
+          if (c0_ == '>') return Select(Token::ARROW);
+          return Token::ASSIGN;
+
+        case Token::NOT:
+          // ! != !==
+          Advance();
+          if (c0_ == '=') return Select('=', Token::NE_STRICT, Token::NE);
+          return Token::NOT;
+//........................
+//代码太多，省略....................
+//........................
+        case Token::PERIOD:
+          // . Number
+          Advance();
+          if (IsDecimalDigit(c0_)) return ScanNumber(true);
+          if (c0_ == '.') {
+            if (Peek() == '.') {
+              Advance();
+              Advance();
+              return Token::ELLIPSIS;
+            }
+          }
+          return Token::PERIOD;
+
+        case Token::TEMPLATE_SPAN:
+          Advance();
+          return ScanTemplateSpan();
+
+        case Token::PRIVATE_NAME:
+          if (source_pos() == 0 && Peek() == '!') {
+            token = SkipSingleLineComment();
+            continue;
+          }
+          return ScanPrivateName();
+
+        case Token::WHITESPACE:
+          token = SkipWhiteSpace();
+          continue;
+
+        case Token::NUMBER:
+          return ScanNumber(false);
+
+        case Token::IDENTIFIER:
+          return ScanIdentifierOrKeyword();
+
+        default:
+          UNREACHABLE();
+      }
+    }
+
+    if (IsIdentifierStart(c0_) ||
+        (CombineSurrogatePair() && IsIdentifierStart(c0_))) {
+      return ScanIdentifierOrKeyword();
+    }
+    if (c0_ == kEndOfInput) {
+      return source_->has_parser_error() ? Token::ILLEGAL : Token::EOS;
+    }
+    token = SkipWhiteSpace();
+
+    // Continue scanning for tokens as long as we're just skipping whitespace.
+  } while (token == Token::WHITESPACE);
+
+  return token;
+}
+```
+上面是`ScanSingleToken()`的源码，内容太多，仅保留了测试样例用到的代码，下面对代码中关键语句进行说明。  
+**(1)：**`if(V8_LIKELY(static_cast<unsigned>(c0_) <= kMaxAscii))`判断`c0_`是不是Ascii，结果是为真(它是`f`)。  
+**(2)：**`token = one_char_tokens[c0_];`这是取获取`c0_`的类型，上篇文章提到的“预定义模板”，说的就是`one_char_tokens`这样的数组，还有其它的宏定义(碰到时再讲)。下面看这个数组的定义：
+```C++
+constexpr Token::Value GetOneCharToken(char c) {
+  // clang-format off
+  return
+      c == '(' ? Token::LPAREN :
+      c == ')' ? Token::RPAREN :
+  //.....................
+  //代码太多，省略
+  //.....................
+      // IsDecimalDigit must be tested before IsAsciiIdentifier
+      IsDecimalDigit(c) ? Token::NUMBER :
+      IsAsciiIdentifier(c) ? Token::IDENTIFIER :
+      Token::ILLEGAL;
+  // clang-format on
+}
+//====分割线========================================================
+#define INT_0_TO_127_LIST(V)                                          \
+V(0)   V(1)   V(2)   V(3)   V(4)   V(5)   V(6)   V(7)   V(8)   V(9)   \
+V(10)  V(11)  V(12)  V(13)  V(14)  V(15)  V(16)  V(17)  V(18)  V(19)  \
+V(20)  V(21)  V(22)  V(23)  V(24)  V(25)  V(26)  V(27)  V(28)  V(29)  \
+V(30)  V(31)  V(32)  V(33)  V(34)  V(35)  V(36)  V(37)  V(38)  V(39)  \
+V(40)  V(41)  V(42)  V(43)  V(44)  V(45)  V(46)  V(47)  V(48)  V(49)  \
+V(50)  V(51)  V(52)  V(53)  V(54)  V(55)  V(56)  V(57)  V(58)  V(59)  \
+V(60)  V(61)  V(62)  V(63)  V(64)  V(65)  V(66)  V(67)  V(68)  V(69)  \
+V(70)  V(71)  V(72)  V(73)  V(74)  V(75)  V(76)  V(77)  V(78)  V(79)  \
+V(80)  V(81)  V(82)  V(83)  V(84)  V(85)  V(86)  V(87)  V(88)  V(89)  \
+V(90)  V(91)  V(92)  V(93)  V(94)  V(95)  V(96)  V(97)  V(98)  V(99)  \
+V(100) V(101) V(102) V(103) V(104) V(105) V(106) V(107) V(108) V(109) \
+V(110) V(111) V(112) V(113) V(114) V(115) V(116) V(117) V(118) V(119) \
+V(120) V(121) V(122) V(123) V(124) V(125) V(126) V(127)
+
+//====分割线========================================================
+static const constexpr Token::Value one_char_tokens[128] = {
+#define CALL_GET_SCAN_FLAGS(N) GetOneCharToken(N),
+    INT_0_TO_127_LIST(CALL_GET_SCAN_FLAGS)
+#undef CALL_GET_SCAN_FLAGS
+};
+```
+上面的代码，用“分割线”分成了三部分，这三部分实现了`one_char_tokens`数组的定义，`c0_`的值是`f`，它符合`IsAsciiIdentifier(c)`,所以它的类型是`Token::IDENTIFIER`。`IsAsciiIdentifier(c)`的源码如下：
+```c++
+inline constexpr bool IsAsciiIdentifier(base::uc32 c) {
+  return IsAlphaNumeric(c) || c == '$' || c == '_';
+}
+```  
+**(3):** 回到`ScanSingleToken()`方法。`c0_`的类型为`Token::IDENTIFIER`，所以进入`ScanIdentifierOrKeyword()`,在这个方法中调用了其它的几个方法，它们的作用是包装类之关的关系，图1给出了这些方法的函数调用堆栈，请读者自行调试跟踪，这里不详细说明。  
+![avatar](f1.png)
+在V8源码中找到相应的位置，下断点，使用样例代码即可还原图1的堆栈。  
+**(4):**`c0_`内容是`f`，下面要继续去找`f`后面的字符，需要存储`f`，`c0_`指向下一个字符，下面是存储方法的代码。  
+```c++
+ V8_INLINE void AddOneByteChar(byte one_byte_char) {//c0_是实参
+    DCHECK(is_one_byte());
+    if (position_ >= backing_store_.length()) ExpandBuffer();
+    backing_store_[position_] = one_byte_char;
+    position_ += kOneByteSize;
+  }
+```
+可以看到，`one_byte_char`就是`c0_`，存储到`backing_store_`中，图2给出了调式模式下`backing_store_`的值。  
+![avatar](f2.png)  
+图2中可以看到`one_byte_char`和`backing_store_`都是`f`。下面开始下一个字符的分析流程。
+```C++
+AdvanceUntil([this, &scan_flags](base::uc32 c0) {
+  if (V8_UNLIKELY(static_cast<uint32_t>(c0) > kMaxAscii)) {
+    // A non-ascii character means we need to drop through to the slow
+    // path.
+    // TODO(leszeks): This would be most efficient as a goto to the slow
+    // path, check codegen and maybe use a bool instead.
+    scan_flags |=
+        static_cast<uint8_t>(ScanFlags::kIdentifierNeedsSlowPath);
+    return true;
+  }
+  uint8_t char_flags = character_scan_flags[c0];
+  scan_flags |= char_flags;
+  if (TerminatesLiteral(char_flags)) {
+    return true;
+  } else {
+    AddLiteralChar(static_cast<char>(c0));
+    return false;
+  }
+});
+```
+上面这个`AdvanceUntil`方法会读取每个字符，至到它遇到一个终结符，图3给出了完成token字`function`分析后的存储信息。  
+![avatar](f3.png)  
+图3中，最后的八个值正好是样例代码的第一个字符串`function`，现在已经得到了一个完整的token字，接下来要判断这个token是关键字或标识符，代码如下。  
+```c++
+V8_INLINE Token::Value KeywordOrIdentifierToken(const uint8_t* input,
+                                                int input_length) {
+  DCHECK_GE(input_length, 1);
+  return PerfectKeywordHash::GetToken(reinterpret_cast<const char*>(input),
+                                      input_length);
+}
+//==============分割线，这是两段代码===============
+inline Token::Value PerfectKeywordHash::GetToken(const char* str, int len) {
+  if (base::IsInRange(len, MIN_WORD_LENGTH, MAX_WORD_LENGTH)) {
+    unsigned int key = Hash(str, len) & 0x3f;
+
+    DCHECK_LT(key, arraysize(kPerfectKeywordLengthTable));
+    DCHECK_LT(key, arraysize(kPerfectKeywordHashTable));
+    if (len == kPerfectKeywordLengthTable[key]) {
+      const char* s = kPerfectKeywordHashTable[key].name;
+
+      while (*s != 0) {
+        if (*s++ != *str++) return Token::IDENTIFIER;
+      }
+      return kPerfectKeywordHashTable[key].value;
+    }
+  }
+  return Token::IDENTIFIER;
+}
+```
+上面给出了两段代码，`GetToken`是判断关键字或标识的具体方法，其原理是预先定义hash表，通过查表确定token的类型，图4给出了这方法执行期间的成员信息。  
+![avatar](f4.png)  
+在图4中可以看到，`kPerfectKeywordHashTable[key].value	FUNCTION (76 'L')	const v8::internal::Token::Value`，与ECMA规范要求完全一致。  
+
+至此，token字`function`生成完毕，它的类型是`Token::FUNCTION`。token字`JsPrint`的生成过程与之类似，不再赘述，它的类型是`Token::IDENTIFIER`。
+# 2.`function`和`JsPrint`之间的关系
+在测试样例代码中，`function`定义函数，`JsPrint`是函数名，这是他们之间的关系。我们在词法分析器中可以看到如下代码：  
+
+```C++
+ParserBase<Impl>::ParseHoistableDeclaration(
+    int pos, ParseFunctionFlags flags, ZonePtrList<const AstRawString>* names,
+    bool default_export) {
+  CheckStackOverflow();
+
+  DCHECK_IMPLIES((flags & ParseFunctionFlag::kIsAsync) != 0,
+                 (flags & ParseFunctionFlag::kIsGenerator) == 0);
+
+  if ((flags & ParseFunctionFlag::kIsAsync) != 0 && Check(Token::MUL)) {
+    // Async generator
+    flags |= ParseFunctionFlag::kIsGenerator;
+  }
+
+  IdentifierT name;
+  FunctionNameValidity name_validity;
+  IdentifierT variable_name;
+  if (peek() == Token::LPAREN) {
+    if (default_export) {
+      impl()->GetDefaultStrings(&name, &variable_name);
+      name_validity = kSkipFunctionNameCheck;
+    } else {
+      ReportMessage(MessageTemplate::kMissingFunctionName);
+      return impl()->NullStatement();
+    }
+  } else {
+    bool is_strict_reserved = Token::IsStrictReservedWord(peek());
+    name = ParseIdentifier();
+    name_validity = is_strict_reserved ? kFunctionNameIsStrictReserved
+                                       : kFunctionNameValidityUnknown;
+    variable_name = name;
+  }
+
+  FuncNameInferrerState fni_state(&fni_);
+  impl()->PushEnclosingName(name);
+
+  FunctionKind function_kind = FunctionKindFor(flags);
+
+  FunctionLiteralT function = impl()->ParseFunctionLiteral(
+      name, scanner()->location(), name_validity, function_kind, pos,
+      FunctionSyntaxKind::kDeclaration, language_mode(), nullptr);
+  //省略很多.......
+  //.........
+```
+上面的代码是对这两个token进行语法分析(parser)，我们明确一点，词法分析(scanner)只负责识别token，它们之间的关系是由语法分析负责识别。
+```C++
+typename ParserBase<Impl>::IdentifierT ParserBase<Impl>::ParseIdentifier(
+    FunctionKind function_kind) {
+  Token::Value next = Next();
+
+  if (!Token::IsValidIdentifier(
+          next, language_mode(), IsGeneratorFunction(function_kind),
+          flags().is_module() ||
+              IsAwaitAsIdentifierDisallowed(function_kind))) {
+    ReportUnexpectedToken(next);
+    return impl()->EmptyIdentifierString();
+  }
+
+  return impl()->GetIdentifier();
+}
+```
+在ParserBase<Impl>::ParseHoistableDeclaration()中，会调用上面的这个方法，在目前，`ParseIdentifier`方法是对`function`和`JsPrint`的分析，它又会引导我们进入下面的符号表(symbol)方法。  
+```c++
+  V8_INLINE const AstRawString* GetSymbol() const {
+    const AstRawString* result = scanner()->CurrentSymbol(ast_value_factory());
+    DCHECK_NOT_NULL(result);
+    return result;
+  }
+```
+在符号表中，程序源代码中的每个标识符都和它的声明或使用信息绑定在一起，`JsPrint`是用`function`定义的一个函数名，所以它两要在符号表中绑定。图5给出了进入符号表时的调用堆栈。  
+![avatar](f5.png)  
+
+正是因为有符号表的存在，我们在调试程序时才能够看到源代码，它是编译阶段生成的数据结构，准确地说符号表在词法分析阶段生成，在语法分析阶段完善和补充。  
+好了，今天到这里，下次见。  
+**微信：qq9123013  备注：v8交流学习    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap4-0917/f1.png b/chap4-0917/f1.png
new file mode 100644
index 0000000..8290589
Binary files /dev/null and b/chap4-0917/f1.png differ
diff --git a/chap4-0917/f2.png b/chap4-0917/f2.png
new file mode 100644
index 0000000..887a1bd
Binary files /dev/null and b/chap4-0917/f2.png differ
diff --git a/chap4-0917/f3.png b/chap4-0917/f3.png
new file mode 100644
index 0000000..c1be2ce
Binary files /dev/null and b/chap4-0917/f3.png differ
diff --git a/chap4-0917/f4.png b/chap4-0917/f4.png
new file mode 100644
index 0000000..f5de884
Binary files /dev/null and b/chap4-0917/f4.png differ
diff --git a/chap4-0917/f5.png b/chap4-0917/f5.png
new file mode 100644
index 0000000..0baee37
Binary files /dev/null and b/chap4-0917/f5.png differ
diff --git a/chap5-0918/README.md b/chap5-0918/README.md
new file mode 100644
index 0000000..e4073e8
--- /dev/null
+++ b/chap5-0918/README.md
@@ -0,0 +1,364 @@
+# 连载《Chrome V8 原理讲解》第五篇 V8语法分析源码讲解
+
+![avatar](../v8.png)
+# 1.摘要
+本次是第五篇，剖析V8语法分析(parser)的源码和工作流程，讲解V8语法分析的核心源码、主要工作流程以及重要数据结构。本文将沿用第四篇文章的“测试样例代码”。
+# 2.语法分析概述  
+语法分析是词法分析（scanner）的下一阶段，词法分析输出（out）的token字是语法分析的输入(in)，语法分析在工作时会频繁使用词法分析器生成token。本文把词法分析器当作黑盒功能使用，直接给出词法分析的token字结果，词法分析器原理参见第四篇文章。
+# 3.源码分析 
+以`function`和`JsPrint`为例详细剖析V8语法分析器的实现原理，从语法分析器的入口函数`DoParseProgram()`入手做起，讲解用户自义函数JsPrint的语法分析过程，之后对延迟分析技术(parse lazily)进行说明。
+## 3.1 语法分析
+下面这段代码是语法分析的入口函数。
+```c++
+FunctionLiteral* Parser::DoParseProgram(Isolate* isolate, ParseInfo* info) {
+  DCHECK_EQ(parsing_on_main_thread_, isolate != nullptr);
+  DCHECK_NULL(scope_);
+  ParsingModeScope mode(this, allow_lazy_ ? PARSE_LAZILY : PARSE_EAGERLY);
+  ResetFunctionLiteralId();
+  FunctionLiteral* result = nullptr;
+  {
+    Scope* outer = original_scope_;
+    DCHECK_NOT_NULL(outer);
+    if (flags().is_eval()) {
+      outer = NewEvalScope(outer);
+    } else if (flags().is_module()) {
+      DCHECK_EQ(outer, info->script_scope());
+      outer = NewModuleScope(info->script_scope());
+    }
+    DeclarationScope* scope = outer->AsDeclarationScope();
+    scope->set_start_position(0);
+
+    FunctionState function_state(&function_state_, &scope_, scope);
+    ScopedPtrList<Statement> body(pointer_buffer());
+    int beg_pos = scanner()->location().beg_pos;
+    if (flags().is_module()) {
+      DCHECK(flags().is_module());
+
+      PrepareGeneratorVariables();
+      Expression* initial_yield =
+          BuildInitialYield(kNoSourcePosition, kGeneratorFunction);
+      body.Add(
+          factory()->NewExpressionStatement(initial_yield, kNoSourcePosition));
+      if (flags().allow_harmony_top_level_await()) {
+        BlockT block = impl()->NullBlock();
+        {
+          StatementListT statements(pointer_buffer());
+          ParseModuleItemList(&statements);
+          if (function_state.suspend_count() > 1) {
+            scope->set_is_async_module();
+            block = factory()->NewBlock(true, statements);
+          } else {
+            statements.MergeInto(&body);
+          }
+        }
+        if (IsAsyncModule(scope->function_kind())) {
+          impl()->RewriteAsyncFunctionBody(
+              &body, block, factory()->NewUndefinedLiteral(kNoSourcePosition));
+        }
+      } else {
+        ParseModuleItemList(&body);
+      }
+      if (!has_error() &&
+          !module()->Validate(this->scope()->AsModuleScope(),
+                              pending_error_handler(), zone())) {
+        scanner()->set_parser_error();
+      }
+    } else if (info->is_wrapped_as_function()) {
+      DCHECK(parsing_on_main_thread_);
+      ParseWrapped(isolate, info, &body, scope, zone());
+    } else if (flags().is_repl_mode()) {
+      ParseREPLProgram(info, &body, scope);
+    } else {
+      this->scope()->SetLanguageMode(info->language_mode());
+      ParseStatementList(&body, Token::EOS);
+    }
+    scope->set_end_position(peek_position());
+    if (is_strict(language_mode())) {
+      CheckStrictOctalLiteral(beg_pos, end_position());
+    }
+    if (is_sloppy(language_mode())) {
+      InsertSloppyBlockFunctionVarBindings(scope);
+    }
+    if (flags().is_eval()) {
+      DCHECK(parsing_on_main_thread_);
+      info->ast_value_factory()->Internalize(isolate);
+    }
+    CheckConflictingVarDeclarations(scope);
+
+    if (flags().parse_restriction() == ONLY_SINGLE_FUNCTION_LITERAL) {
+      if (body.length() != 1 || !body.at(0)->IsExpressionStatement() ||
+          !body.at(0)
+               ->AsExpressionStatement()
+               ->expression()
+               ->IsFunctionLiteral()) {
+        ReportMessage(MessageTemplate::kSingleFunctionLiteral);
+      }
+    }
+    int parameter_count = 0;
+    result = factory()->NewScriptOrEvalFunctionLiteral(
+        scope, body, function_state.expected_property_count(), parameter_count);
+    result->set_suspend_count(function_state.suspend_count());
+  }
+  info->set_max_function_literal_id(GetLastFunctionLiteralId());
+  if (has_error()) return nullptr;
+  RecordFunctionLiteralSourceRange(result);
+  return result;
+}
+```
+`DoParseProgram()`是语法分析的开始，` FunctionLiteral* result = nullptr;`这条语句定义了一个`result`,它是语法分析结束时生成的抽象语法树(AST)，`result`目前为空值，`DoParseProgram()`执行完，AST也就生成了。调试样例代码，进入下面这个方法。
+```c++
+void ParserBase<Impl>::ParseStatementList(StatementListT* body,
+                                          Token::Value end_token) {
+  DCHECK_NOT_NULL(body);
+
+  while (peek() == Token::STRING) {
+    bool use_strict = false;
+#if V8_ENABLE_WEBASSEMBLY
+    bool use_asm = false;
+#endif  // V8_ENABLE_WEBASSEMBLY
+    Scanner::Location token_loc = scanner()->peek_location();
+    if (scanner()->NextLiteralExactlyEquals("use strict")) {
+      use_strict = true;
+#if V8_ENABLE_WEBASSEMBLY
+    } else if (scanner()->NextLiteralExactlyEquals("use asm")) {
+      use_asm = true;
+#endif  // V8_ENABLE_WEBASSEMBLY
+    }
+    StatementT stat = ParseStatementListItem();
+    if (impl()->IsNull(stat)) return;
+    body->Add(stat);
+    if (!impl()->IsStringLiteral(stat)) break;
+    if (use_strict) {
+      RaiseLanguageMode(LanguageMode::kStrict);
+      if (!scope()->HasSimpleParameters()) {
+
+        impl()->ReportMessageAt(token_loc,
+                                MessageTemplate::kIllegalLanguageModeDirective,
+                                "use strict");
+        return;
+      }
+#if V8_ENABLE_WEBASSEMBLY
+    } else if (use_asm) {
+      impl()->SetAsmModule();
+#endif  // V8_ENABLE_WEBASSEMBLY
+    } else {
+      RaiseLanguageMode(LanguageMode::kSloppy);
+    }
+  }
+  while (peek() != end_token) {
+    StatementT stat = ParseStatementListItem();
+    if (impl()->IsNull(stat)) return;
+    if (stat->IsEmptyStatement()) continue;
+    body->Add(stat);
+  }
+}
+```
+上一个方法是语法分析的入口，而`ParseStatementList()`是开始分析程序语句。`while (peek() == Token::STRING)`这条语句，peek是取得token字的类型，这里取来的token是Token::FUNCTION，所以值为假，进入`while (peek() != end_token)`循环，执行`ParseStatementListItem()`方法，在这个方法中进入`Token::FUNCTION`对应的分析功能，代码如下：
+```c++
+ParserBase<Impl>::ParseHoistableDeclaration(
+    ZonePtrList<const AstRawString>* names, bool default_export) {
+  Consume(Token::FUNCTION);//cache机制
+
+  int pos = position();
+  ParseFunctionFlags flags = ParseFunctionFlag::kIsNormal;
+  if (Check(Token::MUL)) {
+    flags |= ParseFunctionFlag::kIsGenerator;
+  }
+  return ParseHoistableDeclaration(pos, flags, names, default_export);
+}
+```
+`Consume()`是第三篇文章中提到的“token字缓存”机制的具体实现，从缓存中取出一个token开始分析，如果缓存缺失(cache miss)，则驱动词法分析器(Scanner)开始工作。从`Consume`取token的方法原理是使Scanner类中的current_成员指向next_成员，再利用next_next判断是否扫描下一个token字，请读者自行查阅代码。  
+
+取出token字`function`、类型函数（Token::FUNCTION），接下来判断该函数属于哪种类型（FunctionKind），FunctionKind的具体代码如下：  
+```c++
+enum FunctionKind : uint8_t {
+  // BEGIN constructable functions
+  kNormalFunction,
+  kModule,
+  kAsyncModule,
+//.................................
+//省略了很多代码
+//.................................
+  // END concise methods 1
+  kAsyncGeneratorFunction,
+  // END async functions
+  kGeneratorFunction,
+  // BEGIN concise methods 2
+  kConciseGeneratorMethod,
+  kStaticConciseGeneratorMethod,
+  // END generators
+  kConciseMethod,
+  kStaticConciseMethod,
+  kClassMembersInitializerFunction,
+  kClassStaticInitializerFunction,
+  // END concise methods 2
+  kInvalid,
+
+  kLastFunctionKind = kClassStaticInitializerFunction,
+};
+```
+不要混淆FunctionKind和Token::FUNCTION的概念，它们属于不同技术领域，Token属于编译技术，FunctionKind属于ECMA规范。在样例代码中，Token字`function`的FunctionKind是`KnormalFunction`,所以下一步是分析这个函数的名字（Token::IDENTIFIER），代码如下：
+```c++
+const AstRawString* Scanner::CurrentSymbol(
+    AstValueFactory* ast_value_factory) const {
+  if (is_literal_one_byte()) {
+    return ast_value_factory->GetOneByteString(literal_one_byte_string());
+  }
+  return ast_value_factory->GetTwoByteString(literal_two_byte_string());
+}
+```
+在`CurrentSymbol()`方法中，进行`one_byte`判断，JsPrint是one_byte类型，`if`语句为真，返回标识符。图1给出了`CurrentSymbol()`方法的函数调用堆栈，方便读者复现代码执行过程。  
+![avatar](f1.png)  
+至此，两个Token字`function`和`JsPrint`语法分析完成，通俗概述以上代码的工作流程如下：  
+**（1）：** 在Javascript源码中，当看到'function'这个字符时，后面应该是一个函数；  
+
+**（2）：** 判断这个函数类型(FunctionKind)，是异步或其它等等，样例代码是kNormalFunction；  
+
+**（3）：** 是kNormalFunction，去获取函数的名字。  
+## 3.2 延迟分析
+什么是延迟分析，延迟分析是V8中一种性能优化技术，即非立即执行的代码先不分析，执行时再做分析。众所周知，一个程序中，代码执行是有先后顺序的，也并不是所有代码都会执行，基于这一点，V8内部实现了延迟分析、延迟编译技术，达到提高效率的目的。下面讲解样例代码为什么会触发延迟分析。
+JsPrint是一个常规(kNormalFunction)方法，取得函数名之后，开始分析函数内容，代码如下：  
+```c++
+FunctionLiteral* Parser::ParseFunctionLiteral(
+    const AstRawString* function_name, Scanner::Location function_name_location,
+    FunctionNameValidity function_name_validity, FunctionKind kind,
+    int function_token_pos, FunctionSyntaxKind function_syntax_kind,
+    LanguageMode language_mode,
+    ZonePtrList<const AstRawString>* arguments_for_wrapped_function) {
+  bool is_wrapped = function_syntax_kind == FunctionSyntaxKind::kWrapped;
+  DCHECK_EQ(is_wrapped, arguments_for_wrapped_function != nullptr);
+  int pos = function_token_pos == kNoSourcePosition ? peek_position()
+                                                    : function_token_pos;
+  DCHECK_NE(kNoSourcePosition, pos);
+  bool should_infer_name = function_name == nullptr;
+
+  if (should_infer_name) {
+    function_name = ast_value_factory()->empty_string();
+  }
+  FunctionLiteral::EagerCompileHint eager_compile_hint =
+      function_state_->next_function_is_likely_called() || is_wrapped
+          ? FunctionLiteral::kShouldEagerCompile
+          : default_eager_compile_hint();
+  DCHECK_IMPLIES(parse_lazily(), info()->flags().allow_lazy_compile());
+  DCHECK_IMPLIES(parse_lazily(), has_error() || allow_lazy_);
+  DCHECK_IMPLIES(parse_lazily(), extension() == nullptr);
+
+  const bool is_lazy =
+      eager_compile_hint == FunctionLiteral::kShouldLazyCompile;
+  const bool is_top_level = AllowsLazyParsingWithoutUnresolvedVariables();
+  const bool is_eager_top_level_function = !is_lazy && is_top_level;
+  const bool is_lazy_top_level_function = is_lazy && is_top_level;
+  const bool is_lazy_inner_function = is_lazy && !is_top_level;
+
+  RCS_SCOPE(runtime_call_stats_, RuntimeCallCounterId::kParseFunctionLiteral,
+            RuntimeCallStats::kThreadSpecific);
+  base::ElapsedTimer timer;
+  if (V8_UNLIKELY(FLAG_log_function_events)) timer.Start();
+  const bool should_preparse_inner = parse_lazily() && is_lazy_inner_function;
+  bool should_post_parallel_task =
+      parse_lazily() && is_eager_top_level_function &&
+      FLAG_parallel_compile_tasks && info()->parallel_tasks() &&
+      scanner()->stream()->can_be_cloned_for_parallel_access();
+
+  // This may be modified later to reflect preparsing decision taken
+  bool should_preparse = (parse_lazily() && is_lazy_top_level_function) ||
+                         should_preparse_inner || should_post_parallel_task;
+  ScopedPtrList<Statement> body(pointer_buffer());
+  int expected_property_count = 0;
+  int suspend_count = -1;
+  int num_parameters = -1;
+  int function_length = -1;
+  bool has_duplicate_parameters = false;
+  int function_literal_id = GetNextFunctionLiteralId();
+  ProducedPreparseData* produced_preparse_data = nullptr;
+  Zone* parse_zone = should_preparse ? &preparser_zone_ : zone();
+  DeclarationScope* scope = NewFunctionScope(kind, parse_zone);
+  SetLanguageMode(scope, language_mode);
+#ifdef DEBUG
+  scope->SetScopeName(function_name);
+#endif
+  if (!is_wrapped && V8_UNLIKELY(!Check(Token::LPAREN))) {
+    ReportUnexpectedToken(Next());
+    return nullptr;
+  }
+  scope->set_start_position(position());
+
+  bool did_preparse_successfully =
+      should_preparse &&
+      SkipFunction(function_name, kind, function_syntax_kind, scope,
+                   &num_parameters, &function_length, &produced_preparse_data);
+  if (!did_preparse_successfully) {
+    if (should_preparse) Consume(Token::LPAREN);
+    should_post_parallel_task = false;
+    ParseFunction(&body, function_name, pos, kind, function_syntax_kind, scope,
+                  &num_parameters, &function_length, &has_duplicate_parameters,
+                  &expected_property_count, &suspend_count,
+                  arguments_for_wrapped_function);
+  }
+  if (V8_UNLIKELY(FLAG_log_function_events)) {
+    double ms = timer.Elapsed().InMillisecondsF();
+    const char* event_name =
+        should_preparse
+            ? (is_top_level ? "preparse-no-resolution" : "preparse-resolution")
+            : "full-parse";
+    logger_->FunctionEvent(
+        event_name, flags().script_id(), ms, scope->start_position(),
+        scope->end_position(),
+        reinterpret_cast<const char*>(function_name->raw_data()),
+        function_name->byte_length(), function_name->is_one_byte());
+  }
+#ifdef V8_RUNTIME_CALL_STATS
+  if (did_preparse_successfully && runtime_call_stats_ &&
+      V8_UNLIKELY(TracingFlags::is_runtime_stats_enabled())) {
+    runtime_call_stats_->CorrectCurrentCounterId(
+        RuntimeCallCounterId::kPreParseWithVariableResolution,
+        RuntimeCallStats::kThreadSpecific);
+  }
+#endif  // V8_RUNTIME_CALL_STATS
+
+  language_mode = scope->language_mode();
+  CheckFunctionName(language_mode, function_name, function_name_validity,
+                    function_name_location);
+
+  if (is_strict(language_mode)) {
+    CheckStrictOctalLiteral(scope->start_position(), scope->end_position());
+  }
+
+  FunctionLiteral::ParameterFlag duplicate_parameters =
+      has_duplicate_parameters ? FunctionLiteral::kHasDuplicateParameters
+                               : FunctionLiteral::kNoDuplicateParameters;
+  FunctionLiteral* function_literal = factory()->NewFunctionLiteral(
+      function_name, scope, body, expected_property_count, num_parameters,
+      function_length, duplicate_parameters, function_syntax_kind,
+      eager_compile_hint, pos, true, function_literal_id,
+      produced_preparse_data);
+  function_literal->set_function_token_position(function_token_pos);
+  function_literal->set_suspend_count(suspend_count);
+
+  RecordFunctionLiteralSourceRange(function_literal);
+
+  if (should_post_parallel_task) {
+    // Start a parallel parse / compile task on the compiler dispatcher.
+    info()->parallel_tasks()->Enqueue(info(), function_name, function_literal);
+  }
+
+  if (should_infer_name) {
+    fni_.AddFunction(function_literal);
+  }
+  return function_literal;
+}
+
+```
+`ParseFunctionLiteral()`，这个方法名字表明了它的主要功能是对函数内容进行语议分析。名字JsPrint分析完成后，进入这个方法分析JsPrint函数的内容，先判断这个方法是否符合延迟分析条件。  
+
+图2是样例代码，可以看出`JsPrint`不会马上执行，并且它是最外部的顶层方法，满足延迟分析条件。从Javascript的执行顺序也可以得到同样的结论：定义JsPrint函数，但代码执行时最先执行的是`console.log()`，`console.log()`执行时需要先计算参数并压栈，所以说JsPrint不是立即执行的，而`console.log()`执行时调用了JsPrint,所以它满足延迟分析条件。
+![avatar](f2.png)    
+调试程序是最有效的验证手段，从代码的角度验证上述结论是否正确， 请读者跟踪`ParseFunctionLiteral()`方法，并查看`is_lazy`和`is_top_level`成员的值，看到这两个成员的值为真，上述结论正确无误，图3给出`ParseFunctionLiteral()`的调用堆栈，便于读者复现代码执行过程。  
+![avatar](f3.png)  
+下面给出`JsPrint()`的抽象语法图，供读者分析学习，如图4。  
+![avatar](f4.png)  
+总结，语法分析器代码逻辑十分复杂，分析代码时做好堆栈记录，有助于在跟踪代码中发生“跟错、跟丢”问题时快速帮你找到最近的正确位置，提高学习效率。  
+
+好了，今天到这里，下次见。   
+
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
diff --git a/chap5-0918/f1.png b/chap5-0918/f1.png
new file mode 100644
index 0000000..81a1d63
Binary files /dev/null and b/chap5-0918/f1.png differ
diff --git a/chap5-0918/f2.png b/chap5-0918/f2.png
new file mode 100644
index 0000000..fe8885b
Binary files /dev/null and b/chap5-0918/f2.png differ
diff --git a/chap5-0918/f3.png b/chap5-0918/f3.png
new file mode 100644
index 0000000..5773b59
Binary files /dev/null and b/chap5-0918/f3.png differ
diff --git a/chap5-0918/f4.png b/chap5-0918/f4.png
new file mode 100644
index 0000000..e23afcd
Binary files /dev/null and b/chap5-0918/f4.png differ
diff --git a/chap6-0922/README.md b/chap6-0922/README.md
new file mode 100644
index 0000000..37a1175
--- /dev/null
+++ b/chap6-0922/README.md
@@ -0,0 +1,257 @@
+# 连载《Chrome V8 原理讲解》第六篇 bytecode字节码生成
+
+![avatar](../v8.png)
+# 1.摘要  
+本次是第六篇，讲解V8中抽象语法树(abstract syntax code,AST)到字节码(bytecode)的翻译过程。AST是源代码的抽象语法结构的树状表示，是语法分析的输出结果，bytecode是一种体系结构无关的、在V8中可以运行的抽象机器码，不依赖指令集。本文中，我们以AST作为V8输入，从AST生成后开始调试(Debug)，讲解bytecode生成过程，分析核心源码和重要数据结构，如图1所示。本文内容的组织方式：介绍字节码，讲解字节码原理，如何看懂字节码(章节2)；AST到bytecode的翻译过程、源码分析(章节3)。  
+![avatar](f1.png)
+# 2.字节码介绍
+字节码是机器码的抽象表示，采用和物理CPU相同的计算模型进行设计。字节码是最小功能完备集，JavaScript源码的任何功能都可以等价转换成字节码的组合。V8有数以百计的字节码，例如`Add`和`Sub`等简单操作，还有`LdaNamedProperty`等属性加载操作。每个字节码都可以指定寄存器作为其操作数，生成字节码的过程中使用寄存器 r0，r1，r2，... 和累加寄存器（accumulator register）。累加器是和其它寄存器一样的常规寄存器，但不同的是累加器的操作没有显式给出指令，具体来说，`Add r1`将寄存器`r1`中的值和累加器中的值进行加法运算，在这个过程不需要显示指出累加器。字节码的定义在v8/src/interpreter/bytecodes.h中，下面展示一部分相关源码。  
+```c++
+#define BYTECODE_LIST_WITH_UNIQUE_HANDLERS(V)                                  \
+  /* Extended width operands */                                                \
+  V(Wide, ImplicitRegisterUse::kNone)                                          \
+  V(ExtraWide, ImplicitRegisterUse::kNone)                                     \
+                                                                               \
+  /* Debug Breakpoints - one for each possible size of unscaled bytecodes */   \
+  /* and one for each operand widening prefix bytecode                    */   \
+  V(DebugBreakWide, ImplicitRegisterUse::kReadWriteAccumulator)                \
+  V(DebugBreakExtraWide, ImplicitRegisterUse::kReadWriteAccumulator)           \
+  V(DebugBreak0, ImplicitRegisterUse::kReadWriteAccumulator)                   \
+  V(DebugBreak1, ImplicitRegisterUse::kReadWriteAccumulator,                   \
+    OperandType::kReg)                                                         \
+  V(DebugBreak2, ImplicitRegisterUse::kReadWriteAccumulator,                   \
+    OperandType::kReg, OperandType::kReg)                                      \
+  V(DebugBreak3, ImplicitRegisterUse::kReadWriteAccumulator,                   \
+    OperandType::kReg, OperandType::kReg, OperandType::kReg)                   \
+  V(DebugBreak4, ImplicitRegisterUse::kReadWriteAccumulator,                   \
+    OperandType::kReg, OperandType::kReg, OperandType::kReg,                   \
+    OperandType::kReg)                                                         \
+  V(DebugBreak5, ImplicitRegisterUse::kReadWriteAccumulator,                   \
+    OperandType::kRuntimeId, OperandType::kReg, OperandType::kReg)             \
+  V(DebugBreak6, ImplicitRegisterUse::kReadWriteAccumulator,                   \
+    OperandType::kRuntimeId, OperandType::kReg, OperandType::kReg,             \
+    OperandType::kReg)                                                         \
+                                                                               \
+  /* Side-effect-free bytecodes -- carefully ordered for efficient checks */   \
+  /* - [Loading the accumulator] */                                            \
+  V(Ldar, ImplicitRegisterUse::kWriteAccumulator, OperandType::kReg)           \
+  V(LdaZero, ImplicitRegisterUse::kWriteAccumulator)                           \
+  V(LdaSmi, ImplicitRegisterUse::kWriteAccumulator, OperandType::kImm)         \
+  V(LdaUndefined, ImplicitRegisterUse::kWriteAccumulator)                      \
+  V(LdaNull, ImplicitRegisterUse::kWriteAccumulator)                           \
+  V(LdaTheHole, ImplicitRegisterUse::kWriteAccumulator)                        \
+  V(LdaTrue, ImplicitRegisterUse::kWriteAccumulator)                           \
+  V(LdaFalse, ImplicitRegisterUse::kWriteAccumulator)                          \
+  V(LdaConstant, ImplicitRegisterUse::kWriteAccumulator, OperandType::kIdx)    \
+  V(LdaContextSlot, ImplicitRegisterUse::kWriteAccumulator, OperandType::kReg, \
+    OperandType::kIdx, OperandType::kUImm)                                     \
+  V(LdaImmutableContextSlot, ImplicitRegisterUse::kWriteAccumulator,           \
+    OperandType::kReg, OperandType::kIdx, OperandType::kUImm)                  \
+  V(LdaCurrentContextSlot, ImplicitRegisterUse::kWriteAccumulator,             \
+    OperandType::kIdx)                                                         \
+  V(LdaImmutableCurrentContextSlot, ImplicitRegisterUse::kWriteAccumulator,    \
+    OperandType::kIdx)                                                         \
+  /* - [Register Loads ] */                                                    \
+  V(Star, ImplicitRegisterUse::kReadAccumulator, OperandType::kRegOut)         \
+  V(Mov, ImplicitRegisterUse::kNone, OperandType::kReg, OperandType::kRegOut)  \
+  V(PushContext, ImplicitRegisterUse::kReadAccumulator, OperandType::kRegOut)  \
+  V(PopContext, ImplicitRegisterUse::kNone, OperandType::kReg)                 \
+  /* - [Test Operations ] */                                                   \
+  V(TestReferenceEqual, ImplicitRegisterUse::kReadWriteAccumulator,            \
+    OperandType::kReg)                                                         \
+  V(TestUndetectable, ImplicitRegisterUse::kReadWriteAccumulator)              \
+  V(TestNull, ImplicitRegisterUse::kReadWriteAccumulator)                      \
+  V(TestUndefined, ImplicitRegisterUse::kReadWriteAccumulator)                 \
+  V(TestTypeOf, ImplicitRegisterUse::kReadWriteAccumulator,                    \
+    OperandType::kFlag8)                                                       \
+//.........省略很多.....
+```
+上面这段代码是字节码的宏定义，用语句`V(Ldar, ImplicitRegisterUse::kWriteAccumulator, OperandType::kReg)`举例说明，`Ldar`是加载数据到累加器，`ImplicitRegisterUse::kWriteAccumulator, OperandType::kReg`说明了`Ldar`指令的源操作数和目的操作数，具体讲两条字节码的含义，如下：  
+**（1）** LdaSmi [1]，这里的[1]是Smi小整型(small int)常量，加载到累加器中，如图2所示。  
+![avatar](f2.png)  
+**（2）** Star r1，这里的r1是r1寄存器，把累加器中的值写入到r1寄存器，目前累加器的值为1，执行完后r1的值为1，如图3所示。  
+![avatar](f3.png)  
+其它字节码指令参见V8的指令定义文件，这里不再赘述。V8为了提升性能，会把多次执行的字节码标记为热点代码，使用优化编译器(TurboFan)把热点代码翻译成机器相关的本地指令，达到提高运行效率的目的，如图4所示。  
+![avatar](f4.png)  
+解释器将AST翻译成字节码比TurboFan用时更短，对于运行次数较少的代码非常合适，即不在运行次数较少的代码上付出更高的编译代价。TurboFan则是对常用代码（热点代码）进行本地化编译，生成体系结构相关的机器码，这需要更长的编译时间，换来的是更快的执行速度。  
+去优化，是将机器码转成字节码，为什么要这样做？原因有很多，详细原因参见TurboFan的定义文件。这里说一个与技术开发人员相关的原因：调试javascript源码，对源码进行调试时，需要转回字节码。  
+# 3.字节码生成
+聊字节码生成之前，先要看明白AST树的结构，明白了AST树结构，也就知道了字节码生成其实是遍历树的过程，落地到程序上就是一个有限状态自动机，具体实现就是`switch case`配合一些预设的宏定义模板，图5给出了AST的数据结构。  
+![avatar](f5.png)  
+AST树的每个节点都继承自`AstNode`这个类，可以说一切皆“AstNode”。`AstNode`的成员方法是最多的，在众多方法中，AstNode的`NodeType`方法无疑是最重要的，因为把一个AstNode节点翻译成字节码时，首先，根据`NodeType`把父类AstNode转成具体的子类，比如，转成表达式(ExPRESSION)或语句(STATEMENT)；其次，才能读取相应的数据、生成字节码，下面的代码是AstNode转成Assignment的具体实现。
+```C++
+void BytecodeGenerator::VisitAssignment(Assignment* expr) {
+  AssignmentLhsData lhs_data = PrepareAssignmentLhs(expr->target());
+
+  VisitForAccumulatorValue(expr->value());
+
+  builder()->SetExpressionPosition(expr);
+  BuildAssignment(lhs_data, expr->op(), expr->lookup_hoisting_mode());
+}
+```  
+在这段代码中，计算`expr->target(),expr->value(),expr->op()`时可能会发生递归调用，因为表达式内可以包含多个子表达式。
+```c++
+void BytecodeGenerator::GenerateBytecodeBody() {
+  // Build the arguments object if it is used.
+  VisitArgumentsObject(closure_scope()->arguments());
+  // Build rest arguments array if it is used.
+  Variable* rest_parameter = closure_scope()->rest_parameter();
+  VisitRestArgumentsArray(rest_parameter);
+  // Build assignment to the function name or {.this_function}
+  // variables if used.
+  VisitThisFunctionVariable(closure_scope()->function_var());
+  VisitThisFunctionVariable(closure_scope()->this_function_var());
+  // Build assignment to {new.target} variable if it is used.
+  VisitNewTargetVariable(closure_scope()->new_target_var());
+  // Create a generator object if necessary and initialize the
+  // {.generator_object} variable.
+  FunctionLiteral* literal = info()->literal();
+  if (IsResumableFunction(literal->kind())) {
+    BuildGeneratorObjectVariableInitialization();
+  }
+  // Emit tracing call if requested to do so.
+  if (FLAG_trace) builder()->CallRuntime(Runtime::kTraceEnter);
+  // Emit type profile call.
+  if (info()->flags().collect_type_profile()) {
+    feedback_spec()->AddTypeProfileSlot();
+    int num_parameters = closure_scope()->num_parameters();
+    for (int i = 0; i < num_parameters; i++) {
+      Register parameter(builder()->Parameter(i));
+      builder()->LoadAccumulatorWithRegister(parameter).CollectTypeProfile(
+          closure_scope()->parameter(i)->initializer_position());
+    }
+  }
+  // Increment the function-scope block coverage counter.
+  BuildIncrementBlockCoverageCounterIfEnabled(literal, SourceRangeKind::kBody);
+  // Visit declarations within the function scope.
+  if (closure_scope()->is_script_scope()) {
+    VisitGlobalDeclarations(closure_scope()->declarations());
+  } else if (closure_scope()->is_module_scope()) {
+    VisitModuleDeclarations(closure_scope()->declarations());
+  } else {
+    VisitDeclarations(closure_scope()->declarations());
+  }
+  // Emit initializing assignments for module namespace imports (if any).
+  VisitModuleNamespaceImports();
+  // The derived constructor case is handled in VisitCallSuper.
+  if (IsBaseConstructor(function_kind())) {
+    if (literal->class_scope_has_private_brand()) {
+      BuildPrivateBrandInitialization(builder()->Receiver());
+    }
+
+    if (literal->requires_instance_members_initializer()) {
+      BuildInstanceMemberInitialization(Register::function_closure(),
+                                        builder()->Receiver());
+    }
+  }
+  // Visit statements in the function body.
+  VisitStatements(literal->body());
+  // Emit an implicit return instruction in case control flow can fall off the
+  // end of the function without an explicit return being present on all paths.
+  if (!builder()->RemainderOfBlockIsDead()) {
+    builder()->LoadUndefined();
+    BuildReturn(literal->return_position());
+  }
+}
+```  
+上面的函数是生成bytecode的入口，最终进入`VisitStatements(literal->body());`，从这里开始生成bytecode，在生成byteocde之前要先使用`AstNode->XXXtype()`获取子类的具体类型，下面给出`XXXtype`的具体实现。
+```C++
+#define DECLARATION_NODE_LIST(V) \
+  V(VariableDeclaration)         \
+  V(FunctionDeclaration)
+
+#define ITERATION_NODE_LIST(V) \
+  V(DoWhileStatement)          \
+  V(WhileStatement)            \
+  V(ForStatement)              \
+  V(ForInStatement)            \
+  V(ForOfStatement)
+
+#define BREAKABLE_NODE_LIST(V) \
+  V(Block)                     \
+  V(SwitchStatement)
+
+#define STATEMENT_NODE_LIST(V)       \
+  ITERATION_NODE_LIST(V)             \
+  BREAKABLE_NODE_LIST(V)             \
+  V(ExpressionStatement)             \
+  V(EmptyStatement)                  \
+  V(SloppyBlockFunctionStatement)    \
+  V(IfStatement)                     \
+  V(ContinueStatement)               \
+  V(BreakStatement)                  \
+  V(ReturnStatement)                 \
+  V(WithStatement)                   \
+  V(TryCatchStatement)               \
+  V(TryFinallyStatement)             \
+  V(DebuggerStatement)               \
+  V(InitializeClassMembersStatement) \
+  V(InitializeClassStaticElementsStatement)
+
+#define LITERAL_NODE_LIST(V) \
+  V(RegExpLiteral)           \
+  V(ObjectLiteral)           \
+  V(ArrayLiteral)
+
+#define EXPRESSION_NODE_LIST(V) \
+  LITERAL_NODE_LIST(V)          \
+  V(Assignment)                 \
+  V(Await)                      \
+  V(BinaryOperation)            \
+//............代码太长，省略很多
+  V(YieldStar)
+
+#define FAILURE_NODE_LIST(V) V(FailureExpression)
+
+#define AST_NODE_LIST(V)                        \
+  DECLARATION_NODE_LIST(V)                      \
+  STATEMENT_NODE_LIST(V)                        \
+  EXPRESSION_NODE_LIST(V)
+//=========分隔线===============================
+#define GENERATE_VISIT_CASE(NodeType)                                   \
+  case AstNode::k##NodeType:                                            \
+    return this->impl()->Visit##NodeType(static_cast<NodeType*>(node));
+
+#define GENERATE_FAILURE_CASE(NodeType) \
+  case AstNode::k##NodeType:            \
+    UNREACHABLE();
+//=========分隔线===============================
+#define GENERATE_AST_VISITOR_SWITCH()        \
+  switch (node->node_type()) {               \
+    AST_NODE_LIST(GENERATE_VISIT_CASE)       \
+    FAILURE_NODE_LIST(GENERATE_FAILURE_CASE) \
+  }
+
+#define DEFINE_AST_VISITOR_SUBCLASS_MEMBERS()               \
+ public:                                                    \
+  void VisitNoStackOverflowCheck(AstNode* node) {           \
+    GENERATE_AST_VISITOR_SWITCH()                           \
+  }                                                         \
+                                                            \
+  void Visit(AstNode* node) {                               \
+    if (CheckStackOverflow()) return;                       \
+    VisitNoStackOverflowCheck(node);                        \
+  }                                                         \
+```
+上述代码中，隔开的三部分代码，组成了AstNode中所有类型(NodeType)的switch语句，第一部分代码和图5的节点类型一一对应。
+```c++
+void BytecodeGenerator::VisitStatements(
+    const ZonePtrList<Statement>* statements) {
+  for (int i = 0; i < statements->length(); i++) {
+    // Allocate an outer register allocations scope for the statement.
+    RegisterAllocationScope allocation_scope(this);
+    Statement* stmt = statements->at(i);
+    Visit(stmt);
+    if (builder()->RemainderOfBlockIsDead()) break;
+  }
+}
+```
+上述代码是bytecode生成的入口，请读者使用图1的样例代码自行跟踪，图6给出`VisitStatements`的函数调用堆栈。  
+![avatar](f6.png)  
+V8中AST到字节码的翻译过程，与编译LLVM中AST到三地址码的翻译相似，读者可自行查阅编译技术相关资料。
+好了，今天到这里，下次见。   
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
+
+
+
diff --git a/chap6-0922/f1.png b/chap6-0922/f1.png
new file mode 100644
index 0000000..606f50e
Binary files /dev/null and b/chap6-0922/f1.png differ
diff --git a/chap6-0922/f2.png b/chap6-0922/f2.png
new file mode 100644
index 0000000..1fc33c3
Binary files /dev/null and b/chap6-0922/f2.png differ
diff --git a/chap6-0922/f3.png b/chap6-0922/f3.png
new file mode 100644
index 0000000..c711d31
Binary files /dev/null and b/chap6-0922/f3.png differ
diff --git a/chap6-0922/f4.png b/chap6-0922/f4.png
new file mode 100644
index 0000000..f6c49ae
Binary files /dev/null and b/chap6-0922/f4.png differ
diff --git a/chap6-0922/f5.png b/chap6-0922/f5.png
new file mode 100644
index 0000000..cc8f6b1
Binary files /dev/null and b/chap6-0922/f5.png differ
diff --git a/chap6-0922/f6.png b/chap6-0922/f6.png
new file mode 100644
index 0000000..f974205
Binary files /dev/null and b/chap6-0922/f6.png differ
diff --git a/chap7-0925/README.md b/chap7-0925/README.md
new file mode 100644
index 0000000..8f64a26
--- /dev/null
+++ b/chap7-0925/README.md
@@ -0,0 +1,288 @@
+# 连载《Chrome V8 原理讲解》第七篇 V8堆栈框架 Stack Frame 
+
+![avatar](../v8.png)
+# 1 摘要   
+本文是第七篇。讲解v8处理函数调用时的底层架构。通过分析运行时函数堆栈，重点对“实际参数少于声明参数”和“实际参数多于声明参数”两种函数调用的stack frame进行详细分析，解释这两种调用方式为什么没有发生堆栈泄露，还能稳定运行、生成正确结果的原因，借此阐述v8堆栈的设计细节。  
+本文中把“实际参数少于声明参数”和“实际参数多于声明参数”称为**实参不匹配**，“实参与函数声明的形参数量相同”称为**正常调用**。本文的组织方式：v8 stack frame介绍（章节2）；stack frame的先导知识--寄存器与参数编码（章节3）；v8刚淘汰的adaptor frame机制（章节4）；v8最新的stack frame机制（章节5）。   
+**关键词：stack frame，caller，callee，bytecode，adaptor frame**  
+
+# 2 stack frame介绍  
+v8在调用函数（callee）之前都会把实际参数压栈，callee会把局部变量压栈。stack frame是一块保留区域，用于存放实参、callee的返回值、局部变量和寄存器。stack frame的创建步骤如下：  
+**（1）** callee的实际参数。如果有，压栈。  
+
+**（2）** callee的返回地址压栈。  
+
+**（3）** callee开始执行，EBP压栈。  
+
+**（4）** 设置EBP等于ESP。*注：EBP现在代表callee的栈基址。*   
+
+**（5）** 如果有局部变量，修改ESP预留栈空间。  
+
+**（6）** 如果需要保存寄存器，压栈。  
+以上六步是常规的函数调用堆栈构建过程，看下面的样例代码，是正常的函数调用。
+```javascript
+function add42(x) {
+  return x + 42;
+}
+add42(91);
+```
+`add42(x)`在V8中的执行过程如图1所示。*注:不考虑优化技术*  
+![avatar](f1.png)  
+图1中，在lazy mode（相关概念参见第五篇文章）情况下，当callee初次执行时，Ignition才生成它的bytecode，安装与体系结构相关的配置，进入callee空间执行，最后再返回到caller。bytecode生成后，开始执行`add42(x)`，stack frame如图2。  
+![avatar](f2.png)  
+图2是callee执行时的stack frame，构建过程由V8中的`InterpreterPushArgsThenCall`负责，`add42(x)`定义时声明了一个参数，调用时也是传入了一个实参91，这是一个正常的函数调用，调用结束后正常退出，正常清理堆栈。看下面两种非常普遍的情况：  
+
+**（1）** 调用函数不传实参，`add42()`  
+
+**（2）** 调用函数传入多个实参，`add42(91,1,2)`  
+
+这两种情况属于“实参不匹配”，在sloppy mode下不会报错，正常执行，`add42(91,1,2)`还会返回正确的结果133。众所周知，“实参不匹配”时，calee退出时可能发生堆栈泄露。本文剩余篇幅讲解V8如何做到“实参不匹配”的正确运行，既能有正确的返回结果(133)，又不发生堆栈泄露。  
+# 3 寄存器与参数编码  
+了解bytecode中寄存器和函数参数的编码方式，有助于理解stack frame的原理。调用`add42(91)`生成的bytecode如下：  
+```c++
+0d              LdaUndefined              //加载undefined到累加器
+26 f9           Star r2                   //累加器的值存入r2寄存器
+13 01 00        LdaGlobal [1]             //加载全局指针(add42)到累加器
+26 fa           Star r1                   //累加器的值存入r1
+0c 03           LdaSmi [91]               //加载小整型数91到累加器
+26 f8           Star r3                   //累加器的值存入r3
+5f fa f9 02     CallNoFeedback r1, r2-r3  //调用add42(x)
+```   
+寄存器用非负单字节整数编码，r1的编码是fa，r2是f9，以此类推。`5f fa f9 02     CallNoFeedback r1, r2-r3`中，`fa`代表r1寄存器，`f9`代表r2寄存器，`02`表示长度为2，`f9 02`联合表示：以r2开始，长度为2的寄存器列表。  
+
+```c++
+25 02             Ldar a0          //加载第一个参数到累加器
+40 2a 00          AddSmi [42]      //累加器 +=42
+ab                Return           //返回累加器
+```  
+上面是执行`add42(x)`函数的bytecode，第一个参数（a0）的数字编码是02。  
+这种编码其实是stack frame的偏移量，见图2，fa补码（two's complement）是6，FP减6正好是r1寄存器，a0补码是2，FP加2正好是第一个实参91。这种编码方式的优点：通过简单的FP加减操作，实现了对参数和寄存器的快速访问，简化了字节码的设计。**注意：** 由于v8版本更新迭代快，不同版v8的编码实现存在细微差别，但编码思路是相同的，并且v8中规定了寄器存访问公式：r[i]=FP-2-kFixedFrameHeaderSize-i，参数访问公式：a[i]=FP+2+parameter_count-i-1，parameter_count表示参数的数量。
+# 4 adaptor frame机制  
+沿用多年的adaptor frame机制已经被淘汰，但了解adaptor frame机制，有助理解v8中新stack frame机制的原理和设计初衷。下面是“实参不匹配”的调用:  
+```c++
+add42()
+add42(91,1,2,)
+```  
+众所周知，`add42()`的结果是undefined+42=NaN；`add42(91,1,2)`的结果是91+42=133；这两个函数都正常执行，没发生堆栈泄露，并且返回结果133，图3给出了stack frame的镜像。  
+![avatar](f3.png)  
+与图2对比，可知stack frame中新增了adaptor frame结构(黄色标记)。adaptor frame中有两个重要数据：  
+**（1）**Number of arguments，它记录了`add42(x)`调用时的参数数量。这个数值在编译期，通过查询对应的JSFunction获得，对于`add42(x)`，它的值为1。  
+**（2）**实参slot，存储了`add42(x)`调用时传入的实参，数量由Number of arguments决定。  
+在执行`add42()`时，缺少一个实参，用一个Undefined填充实参slot，见图3中左侧的stack frame。  
+另一个`add42(91,1,2)`中，虽然入栈三个实数，但根据Number of arguments得知，只需要一个实参，取第一个参数91填充实参slot。  
+之后，进入`add42(x)`开始执行，它所需要的实数从Adaptor Frame中读取的，和Caller Frame没有关系。`add42(x)`执行时可以准确地读取实数，Undefinded或91，这变成了正常调用。  
+总结，Adaptor Frame的作用是改变“实参不匹配”为“正常调用”，其本质是caller和callee之间的纽带，负责计算存callee所需要的实参，并从caller中取来，缺失时用undefined补上，多余的忽略。入压时已经保存了Saved FP和Saved Adaptor FP，callee退栈到Adaptor Frame，Adaptor Frame退栈到caller，所以不会发生堆栈泄露。  
+为什么v8淘汰Adaptor Frame？因为性能损耗，调用一次callee，要发生两次stack Frame构建，一次是构建Adaptor Frame，另一次是构建callee Frame，这是很耗时的，所以要淘汰。  
+# 5 最新的stack frame机制  
+出于性能优化的考虑，2021年初，服役多年的adaptor frame退出了历史舞台，新版stack frame机制如图4所示。  
+![avatar](f4.png)  
+它的创新点是省去adaptor frame，将函数调用时的堆栈构建减少一次，但保留Number of Arguments。   
+新版stack frame机制必须满足以下四点要求，这更是v8团队设计这种新stack frame机制的初衷：  
+**（1）** 满足章节2中介绍的用偏移量访问参数和寄存器的方式。  
+
+**（2）** 必须能处理“实参不匹配”的函数调用，`add42()`和`add42(91,1,2)`都可以正常执行。 
+
+**（3）** callee退出，实现堆栈正常清理，这是必须的！ 
+
+**（4）** 抛弃adaptor frame，因为它太消耗性能。 
+
+下面详细说明图4的新stack frame机制如何满足以上四点要求：  
+针对第(1)点要求，入压方式不变，编码方式不变，一定满足，读者可以计算验证，不再赘述。  
+
+针对第(2)点要求，Number of arguments的作用与上面的一样，记录callee需要的实参数量，`add42(x)`的Number of arguments是1。v8约定：callee的实参由右向左压入caller Frame，压入数量取实际数量和Number of arguments的最大值。`add42(91,1,2)`调用时，实际数量是3(91,1,2)个，入栈3个实参，依次为2,1,91。`add42()`调用时，实际数量是0个，Number of arguments是1，要入栈1个实参，用Undefined填充。进入`add42(x)`执行，它可以得到期望的参数(91或Undefined)，此需求满足。  
+
+针对第(3)点要求，图4中入栈方式是常规的入栈，所以退出时不存在任何问题。  
+
+针对第(4)点要求，已经满足了，adaptor frame suddenly disappeared!!!   
+下面给出上述功能的关键入口函数，供读者复现学习。  
+```c++
+void Builtins::Generate_InterpreterPushArgsThenCallImpl(
+    MacroAssembler* masm, ConvertReceiverMode receiver_mode,
+    InterpreterPushArgsMode mode) {
+  DCHECK(mode != InterpreterPushArgsMode::kArrayFunction);
+  // ----------- S t a t e -------------
+  //  -- rax : the number of arguments (not including the receiver)
+  //  -- rbx : the address of the first argument to be pushed. Subsequent
+  //           arguments should be consecutive above this, in the same order as
+  //           they are to be pushed onto the stack.
+  //  -- rdi : the target to call (can be any Object).
+  // -----------------------------------
+  Label stack_overflow;
+
+  if (mode == InterpreterPushArgsMode::kWithFinalSpread) {
+    // The spread argument should not be pushed.
+    __ decl(rax);
+  }
+
+  __ leal(rcx, Operand(rax, 1));  // Add one for receiver.
+
+  // Add a stack check before pushing arguments.
+  __ StackOverflowCheck(rcx, &stack_overflow);
+
+  // Pop return address to allow tail-call after pushing arguments.
+  __ PopReturnAddressTo(kScratchRegister);
+
+  if (receiver_mode == ConvertReceiverMode::kNullOrUndefined) {
+    // Don't copy receiver.
+    __ decq(rcx);
+  }
+
+  // rbx and rdx will be modified.
+  GenerateInterpreterPushArgs(masm, rcx, rbx, rdx);
+
+  // Push "undefined" as the receiver arg if we need to.
+  if (receiver_mode == ConvertReceiverMode::kNullOrUndefined) {
+    __ PushRoot(RootIndex::kUndefinedValue);
+  }
+
+  if (mode == InterpreterPushArgsMode::kWithFinalSpread) {
+    // Pass the spread in the register rbx.
+    // rbx already points to the penultime argument, the spread
+    // is below that.
+    __ movq(rbx, Operand(rbx, -kSystemPointerSize));
+  }
+
+  // Call the target.
+  __ PushReturnAddressFrom(kScratchRegister);  // Re-push return address.
+
+  if (mode == InterpreterPushArgsMode::kWithFinalSpread) {
+    __ Jump(BUILTIN_CODE(masm->isolate(), CallWithSpread),
+            RelocInfo::CODE_TARGET);
+  } else {
+    __ Jump(masm->isolate()->builtins()->Call(receiver_mode),
+            RelocInfo::CODE_TARGET);
+  }
+
+  // Throw stack overflow exception.
+  __ bind(&stack_overflow);
+  {
+    __ TailCallRuntime(Runtime::kThrowStackOverflow);
+    // This should be unreachable.
+    __ int3();
+  }
+}
+//=======================================
+//======分割线==========================
+//=======================================
+void Builtins::Generate_InterpreterPushArgsThenConstructImpl(
+    MacroAssembler* masm, InterpreterPushArgsMode mode) {
+  // ----------- S t a t e -------------
+  //  -- rax : the number of arguments (not including the receiver)
+  //  -- rdx : the new target (either the same as the constructor or
+  //           the JSFunction on which new was invoked initially)
+  //  -- rdi : the constructor to call (can be any Object)
+  //  -- rbx : the allocation site feedback if available, undefined otherwise
+  //  -- rcx : the address of the first argument to be pushed. Subsequent
+  //           arguments should be consecutive above this, in the same order as
+  //           they are to be pushed onto the stack.
+  // -----------------------------------
+  Label stack_overflow;
+
+  // Add a stack check before pushing arguments.
+  __ StackOverflowCheck(rax, &stack_overflow);
+
+  // Pop return address to allow tail-call after pushing arguments.
+  __ PopReturnAddressTo(kScratchRegister);
+
+  if (mode == InterpreterPushArgsMode::kWithFinalSpread) {
+    // The spread argument should not be pushed.
+    __ decl(rax);
+  }
+
+  // rcx and r8 will be modified.
+  GenerateInterpreterPushArgs(masm, rax, rcx, r8);
+
+  // Push slot for the receiver to be constructed.
+  __ Push(Immediate(0));
+
+  if (mode == InterpreterPushArgsMode::kWithFinalSpread) {
+    // Pass the spread in the register rbx.
+    __ movq(rbx, Operand(rcx, -kSystemPointerSize));
+    // Push return address in preparation for the tail-call.
+    __ PushReturnAddressFrom(kScratchRegister);
+  } else {
+    __ PushReturnAddressFrom(kScratchRegister);
+    __ AssertUndefinedOrAllocationSite(rbx);
+  }
+
+  if (mode == InterpreterPushArgsMode::kArrayFunction) {
+    // Tail call to the array construct stub (still in the caller
+    // context at this point).
+    __ AssertFunction(rdi);
+    // Jump to the constructor function (rax, rbx, rdx passed on).
+    Handle<Code> code = BUILTIN_CODE(masm->isolate(), ArrayConstructorImpl);
+    __ Jump(code, RelocInfo::CODE_TARGET);
+  } else if (mode == InterpreterPushArgsMode::kWithFinalSpread) {
+    // Call the constructor (rax, rdx, rdi passed on).
+    __ Jump(BUILTIN_CODE(masm->isolate(), ConstructWithSpread),
+            RelocInfo::CODE_TARGET);
+  } else {
+    DCHECK_EQ(InterpreterPushArgsMode::kOther, mode);
+    // Call the constructor (rax, rdx, rdi passed on).
+    __ Jump(BUILTIN_CODE(masm->isolate(), Construct), RelocInfo::CODE_TARGET);
+  }
+
+  // Throw stack overflow exception.
+  __ bind(&stack_overflow);
+  {
+    __ TailCallRuntime(Runtime::kThrowStackOverflow);
+    // This should be unreachable.
+    __ int3();
+  }
+}
+```  
+以上代码是两功能函数，给出了即将执行callee之前，做的一些与体系结构相关的准备工作，我的平台是x64架构，所以上述代码取自builtins-x64.cc，读者可以debug调式学习。
+```c++
+void Builtins::Generate_Call(MacroAssembler* masm, ConvertReceiverMode mode) {
+  // ----------- S t a t e -------------
+  //  -- rax : the number of arguments (not including the receiver)
+  //  -- rdi : the target to call (can be any Object)
+  // -----------------------------------
+  StackArgumentsAccessor args(rax);
+
+  Label non_callable;
+  __ JumpIfSmi(rdi, &non_callable);
+  __ LoadMap(rcx, rdi);
+  __ CmpInstanceTypeRange(rcx, FIRST_JS_FUNCTION_TYPE, LAST_JS_FUNCTION_TYPE);
+  __ Jump(masm->isolate()->builtins()->CallFunction(mode),
+          RelocInfo::CODE_TARGET, below_equal);
+
+  __ CmpInstanceType(rcx, JS_BOUND_FUNCTION_TYPE);
+  __ Jump(BUILTIN_CODE(masm->isolate(), CallBoundFunction),
+          RelocInfo::CODE_TARGET, equal);
+
+  // Check if target has a [[Call]] internal method.
+  __ testb(FieldOperand(rcx, Map::kBitFieldOffset),
+           Immediate(Map::Bits1::IsCallableBit::kMask));
+  __ j(zero, &non_callable, Label::kNear);
+
+  // Check if target is a proxy and call CallProxy external builtin
+  __ CmpInstanceType(rcx, JS_PROXY_TYPE);
+  __ Jump(BUILTIN_CODE(masm->isolate(), CallProxy), RelocInfo::CODE_TARGET,
+          equal);
+
+  // 2. Call to something else, which might have a [[Call]] internal method (if
+  // not we raise an exception).
+
+  // Overwrite the original receiver with the (original) target.
+  __ movq(args.GetReceiverOperand(), rdi);
+  // Let the "call_as_function_delegate" take care of the rest.
+  __ LoadNativeContextSlot(rdi, Context::CALL_AS_FUNCTION_DELEGATE_INDEX);
+  __ Jump(masm->isolate()->builtins()->CallFunction(
+              ConvertReceiverMode::kNotNullOrUndefined),
+          RelocInfo::CODE_TARGET);
+
+  // 3. Call to something that is not callable.
+  __ bind(&non_callable);
+  {
+    FrameScope scope(masm, StackFrame::INTERNAL);
+    __ Push(rdi);
+    __ CallRuntime(Runtime::kThrowCalledNonCallable);
+  }
+}
+```  
+本文只讲解callee为函数的情况(根据ECMA规范，callee还可以是构造体，等等。)，此时上述代码是执行callee的入口函数，`Generate_Call`的第一个参数`MacroAssembler* masm`以及它内部的指令，如` __ JumpIfSmi(rdi, &non_callable);`都说明了这里执行bytecode，读者可以自行debug调试。  
+从这里开始，后续会用到汇编知识，经常在没有源码的情况下进行汇编调试。    
+好了，今天到这里，下次见。  
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap7-0925/f1.png b/chap7-0925/f1.png
new file mode 100644
index 0000000..9e837cf
Binary files /dev/null and b/chap7-0925/f1.png differ
diff --git a/chap7-0925/f2.png b/chap7-0925/f2.png
new file mode 100644
index 0000000..8d4199e
Binary files /dev/null and b/chap7-0925/f2.png differ
diff --git a/chap7-0925/f3.png b/chap7-0925/f3.png
new file mode 100644
index 0000000..b96e51d
Binary files /dev/null and b/chap7-0925/f3.png differ
diff --git a/chap7-0925/f4.png b/chap7-0925/f4.png
new file mode 100644
index 0000000..00e81f7
Binary files /dev/null and b/chap7-0925/f4.png differ
diff --git a/chap8-0929/README.md b/chap8-0929/README.md
new file mode 100644
index 0000000..2705ac6
--- /dev/null
+++ b/chap8-0929/README.md
@@ -0,0 +1,324 @@
+# 连载《Chrome V8 原理讲解》第八篇 解释器Ignition
+![avatar](../v8.png)
+# 1 摘要 
+本次是第八篇，讲解v8解释器Ignition的工作流程。Ignition是基于寄存器的解释器，本过通过分析Ignition重要源码和核心数据结构、讲解bytecode的加载和执行过程，详细阐述Ignition的工作流程。  
+本文内容的组织方式：讲解Ignition的先导知识--Builtin是什么、具体实现以及调试方法（章节2）;Ignition工作流程、原理讲解、源码分析（章节3）。    
+**关键字** bytecode handler（字节码处理程序），dispatch，Builtin,Ignition  
+
+# 2 Builtin
+学习Ignition，绕不开Builtin，因为Ignition的大部分功能由Builtin实现。Builtin（built in function）是V8的内建功能，它是V8运行时可执行的代码块，实现Builtin功能的方式主要有：Javascript、C++、汇编、CodeStubAssembler四种方式。其中，CodeStubAssembler是一种平台无关（platform-independent）的抽象语言，由TurbFan编译生成。Builtin有很多种，以TF_BUILTIN举例说明，下面是它的宏定义模板:
+```C++
+#define TF_BUILTIN(Name, AssemblerBase)                                     \
+  class Name##Assembler : public AssemblerBase {                            \
+   public:                                                                  \
+    using Descriptor = Builtin_##Name##_InterfaceDescriptor;                \
+                                                                            \
+    explicit Name##Assembler(compiler::CodeAssemblerState* state)           \
+        : AssemblerBase(state) {}                                           \
+    void Generate##Name##Impl();                                            \
+                                                                            \
+    template <class T>                                                      \
+    TNode<T> Parameter(                                                     \
+        Descriptor::ParameterIndices index,                                 \
+        cppgc::SourceLocation loc = cppgc::SourceLocation::Current()) {     \
+      return CodeAssembler::Parameter<T>(static_cast<int>(index), loc);     \
+    }                                                                       \
+                                                                            \
+    template <class T>                                                      \
+    TNode<T> UncheckedParameter(Descriptor::ParameterIndices index) {       \
+      return CodeAssembler::UncheckedParameter<T>(static_cast<int>(index)); \
+    }                                                                       \
+  };                                                                        \
+  void Builtins::Generate_##Name(compiler::CodeAssemblerState* state) {     \
+    Name##Assembler assembler(state);                                       \
+    state->SetInitialDebugInformation(#Name, __FILE__, __LINE__);           \
+    if (Builtins::KindOf(Builtin::k##Name) == Builtins::TFJ) {              \
+      assembler.PerformStackCheck(assembler.GetJSContextParameter());       \
+    }                                                                       \
+    assembler.Generate##Name##Impl();                                       \
+  }                                                                         \
+  void Name##Assembler::Generate##Name##Impl()
+```  
+上述代码中，`AssemblerBase`是Builtin功能父类，功能不同，其父类也不同，通过下面的代码举例说明：
+```c++
+TF_BUILTIN(CloneFastJSArrayFillingHoles, ArrayBuiltinsAssembler) {
+  auto context = Parameter<Context>(Descriptor::kContext);
+  auto array = Parameter<JSArray>(Descriptor::kSource);
+
+  CSA_ASSERT(this,
+             Word32Or(Word32BinaryNot(IsHoleyFastElementsKindForRead(
+                          LoadElementsKind(array))),
+                      Word32BinaryNot(IsNoElementsProtectorCellInvalid())));
+
+  Return(CloneFastJSArray(context, array, base::nullopt,
+                          HoleConversionMode::kConvertToUndefined));
+}
+```
+上述代码是一个具体的Builtin功能实现，`CloneFastJSArrayFillingHoles`是Builtin功能的名字，`ArrayBuiltinsAssembler`是它的父类。名字不同，功能不同，其父类自然也不同。但是，所有Builtin均继承自同一个顶层的父类`CodeStubAssembler`，代码如下：
+```c++
+class V8_EXPORT_PRIVATE CodeStubAssembler
+    : public compiler::CodeAssembler,
+      public TorqueGeneratedExportedMacrosAssembler {
+ public:
+  using ScopedExceptionHandler = compiler::ScopedExceptionHandler;
+
+  template <typename T>
+  using LazyNode = std::function<TNode<T>()>;
+
+  explicit CodeStubAssembler(compiler::CodeAssemblerState* state);
+
+  enum AllocationFlag : uint8_t {
+    kNone = 0,
+    kDoubleAlignment = 1,
+    kPretenured = 1 << 1,
+    kAllowLargeObjectAllocation = 1 << 2,
+  };
+
+  enum SlackTrackingMode { kWithSlackTracking, kNoSlackTracking };
+
+  using AllocationFlags = base::Flags<AllocationFlag>;
+
+  TNode<IntPtrT> ParameterToIntPtr(TNode<Smi> value) { return SmiUntag(value); }
+  TNode<IntPtrT> ParameterToIntPtr(TNode<IntPtrT> value) { return value; }
+  TNode<IntPtrT> ParameterToIntPtr(TNode<UintPtrT> value) {
+    return Signed(value);
+  }
+
+  enum InitializationMode {
+    kUninitialized,
+    kInitializeToZero,
+    kInitializeToNull
+  };
+//........................
+//代码近4000行，以下部分省略......................
+//........................
+```
+代码太多，请自行查阅。下面给出Builtin列表，它包含了所有的Builtin，是一个宏模板，里面又嵌套了不同子类型的Builtin宏模板。
+```c++
+#define BUILTIN_LIST(CPP, TFJ, TFC, TFS, TFH, BCH, ASM)  \
+  BUILTIN_LIST_BASE(CPP, TFJ, TFC, TFS, TFH, ASM)        \
+  BUILTIN_LIST_FROM_TORQUE(CPP, TFJ, TFC, TFS, TFH, ASM) \
+  BUILTIN_LIST_INTL(CPP, TFJ, TFS)                       \
+  BUILTIN_LIST_BYTECODE_HANDLERS(BCH)
+```
+Builtin的编写规则，本文不做介绍，想学习的读者可以留言联系我，也可查阅官方文档。  
+下面讲debug跟踪Builtin功能的方法，分析Ignition工作流程时离不开debug调试。无论Builtin的实现方式是js亦或C++，都只能做汇编调试，因为Builtin的实现与V8分离，单独生成个`snapshot_blob.bin`文件，保存在磁盘上，V8启动时将其进行反序列化，读取到内存中，这样做为了提升V8的启动速度。7.9版之前的V8，支持Builtin的C++调试，请读者自行分析，有问题可以联系我。  
+Ignition执行字节码的入口是`InterpreterEntryTrampoline`，它是一个Builtin，它的功能和具体实现稍后讲解，下面看如何debug跟踪它。
+```C++
+enum class Builtin : int32_t {
+  kNoBuiltinId = -1,
+#define DEF_ENUM(Name, ...) k##Name,
+  BUILTIN_LIST(DEF_ENUM, DEF_ENUM, DEF_ENUM, DEF_ENUM, DEF_ENUM, DEF_ENUM,
+               DEF_ENUM)
+#undef DEF_ENUM
+#define EXTRACT_NAME(Name, ...) k##Name,
+  // Define kFirstBytecodeHandler,
+  kFirstBytecodeHandler =
+      FirstFromVarArgs(BUILTIN_LIST_BYTECODE_HANDLERS(EXTRACT_NAME) 0)
+#undef EXTRACT_NAME
+};
+```  
+首先，看上面的`Builtin`类结构,每一个Builtin功能都有一个枚举编号，根据`BUILTIN_LIST`宏模板的定义顺序，可以计算出`InterpreterEntryTrampoline`的枚举编号，用这个编码做数组下标在图1中找到对应的数组成员，这个`isolate->isolate_data_.builtins_`成员是`BUILTIN`数组。  
+
+![avatar](f1.png)  
+根据数组成员中存储的内存地址，进行汇编级调试。此外，另一个跟踪方法是从`i::Excetuion::Call()`方法进行跟踪，最终也是进入汇编代码，不再赘述。开始跟踪之前，一定要先分析重要的数据结构，学习相关原理，例如V8的堆栈布局(stack layout)等，这会使调试Builtin事半功倍。V8是一个庞大的系统，涉及了编译技术、体系结构、操作系统等众多知识领域，有相应的知识储备可以使学习V8的过程更容易一些。
+# 3 Ignition解释器
+前面介绍了Ignition的调试方法，本节详细讲解Ignition源码的具体实现和工作流程，Ignition是V8解释器，负责执行字节码，它的输入一个字节码列表（bytecode array），输出是程序的执行结果。先给出几个重要约定：  
+
+**（1）** bytecode handler，字节码处理程序，每个字节码对应一个处理程序，Ignition解释执行字节码的本质就是执行对应的处理程序。 
+
+**（2）** bytecode array，字节码列表，一个Javascript功能编译完后生字节码列表。执行字节码之前，需要做预先的准备，包括构建堆栈，参数入压等等，具体工作由`InterpreterEntryTrampoline`负责。  
+
+**（3）** 每一条字节码执行完后，都要调用`Dispatch()`，这个函数负责跳转到下一条字节码开始执行。  
+
+**（4）** Ignition是一个基于寄存器的解释器，这些寄存器是V8维护的虚拟寄存器，用栈实现，不是物理寄存器。但有一个例外，Ignition有一个累加器寄存器，它被很多字节码作为隐式的输入输出寄存器，它是物理寄存器。  
+
+**（5）** dispatch table,字节码分发表，每个isolate都包含一个全局的字节码分发表，分发表以字节码的枚举值作为索引，表项是字节码处理程序的对象指针。  
+以上五点约定的功能均写入了`snapshot_blob.bin`文件，在V8启动时通过反序列化方式加载。  
+`InterpreterEntryTrampoline`的源码实现如下：  
+```c++
+void Builtins::Generate_InterpreterEntryTrampoline(MacroAssembler* masm) {
+  Register closure = rdi;
+  Register feedback_vector = rbx;
+
+  // Get the bytecode array from the function object and load it into
+  // kInterpreterBytecodeArrayRegister.
+  __ LoadTaggedPointerField(
+      kScratchRegister,
+      FieldOperand(closure, JSFunction::kSharedFunctionInfoOffset));
+  __ LoadTaggedPointerField(
+      kInterpreterBytecodeArrayRegister,
+      FieldOperand(kScratchRegister, SharedFunctionInfo::kFunctionDataOffset));
+
+  Label is_baseline;
+  GetSharedFunctionInfoBytecodeOrBaseline(
+      masm, kInterpreterBytecodeArrayRegister, kScratchRegister, &is_baseline);
+
+  // The bytecode array could have been flushed from the shared function info,
+  // if so, call into CompileLazy.
+  Label compile_lazy;
+  __ CmpObjectType(kInterpreterBytecodeArrayRegister, BYTECODE_ARRAY_TYPE,
+                   kScratchRegister);
+  __ j(not_equal, &compile_lazy);
+
+  // Load the feedback vector from the closure.
+  __ LoadTaggedPointerField(
+      feedback_vector, FieldOperand(closure, JSFunction::kFeedbackCellOffset));
+  __ LoadTaggedPointerField(feedback_vector,
+                            FieldOperand(feedback_vector, Cell::kValueOffset));
+
+  Label push_stack_frame;
+  // Check if feedback vector is valid. If valid, check for optimized code
+  // and update invocation count. Otherwise, setup the stack frame.
+  __ LoadMap(rcx, feedback_vector);
+  __ CmpInstanceType(rcx, FEEDBACK_VECTOR_TYPE);
+  __ j(not_equal, &push_stack_frame);
+
+  // Check for an optimization marker.
+  Label has_optimized_code_or_marker;
+  Register optimization_state = rcx;
+  LoadOptimizationStateAndJumpIfNeedsProcessing(
+      masm, optimization_state, feedback_vector, &has_optimized_code_or_marker);
+//........................
+//代码太长，以下部分省略......................
+//........................
+
+}
+```
+`InterpreterEntryTrampoline`的作用是构建调用堆栈，分配部局变量等，图2给出了一种`InterpreterEntryTrampoline`构建的栈布局，不同类型函数有不同的堆栈，第七篇文章中讲的堆栈也是由这个函数构建的。上述代码中`GetSharedFunctionInfoBytecodeOrBaseline`是取得bytecode array，通过每一个`Label`可以看出要执行的功能，`__`的具体实现是`#define __ ACCESS_MASM(masm)`，之后会调用bytecode array的第一条bytecode，开始执行。  
+![avatar](f2.png)  
+
+`Builtins`类中还定义了其它一些重要的函数，见下面源码：
+```C++
+class Builtins {
+//........................
+//代码太长，省略很多.......
+//........................
+  static void Generate_CallFunction(MacroAssembler* masm,
+                                    ConvertReceiverMode mode);
+
+  static void Generate_CallBoundFunctionImpl(MacroAssembler* masm);
+
+  static void Generate_Call(MacroAssembler* masm, ConvertReceiverMode mode);
+
+  enum class CallOrConstructMode { kCall, kConstruct };
+  static void Generate_CallOrConstructVarargs(MacroAssembler* masm,
+                                              Handle<Code> code);
+  static void Generate_CallOrConstructForwardVarargs(MacroAssembler* masm,
+                                                     CallOrConstructMode mode,
+                                                     Handle<Code> code);
+
+  static void Generate_InterpreterPushArgsThenCallImpl(
+      MacroAssembler* masm, ConvertReceiverMode receiver_mode,
+      InterpreterPushArgsMode mode);
+
+  static void Generate_InterpreterPushArgsThenConstructImpl(
+      MacroAssembler* masm, InterpreterPushArgsMode mode);
+
+  template <class Descriptor>
+  static void Generate_DynamicCheckMapsTrampoline(MacroAssembler* masm,
+                                                  Handle<Code> builtin_target);
+
+#define DECLARE_ASM(Name, ...) \
+  static void Generate_##Name(MacroAssembler* masm);
+#define DECLARE_TF(Name, ...) \
+  static void Generate_##Name(compiler::CodeAssemblerState* state);
+
+  BUILTIN_LIST(IGNORE_BUILTIN, DECLARE_TF, DECLARE_TF, DECLARE_TF, DECLARE_TF,
+               IGNORE_BUILTIN, DECLARE_ASM)
+//........................
+//代码太长，以下部分省略......................
+//........................
+```
+`Builtins`类中的`#define DECLARE_TF(Name, ...)`和`#define DECLARE_ASM(Name, ...)`是所有Builtin的生成函数，它们是由Turbofan生成，每一条bytecode的执行，由一个具体的bytecode handler负责。**注意：bytecode handler只是一种Builtin，还有其它的Builtin功能，byteocde是Builtin，Builtin并不都是bytecode！**  
+
+下面是生成bytecode handler的功能代码：
+```c++
+#define IGNITION_HANDLER(Name, BaseAssembler)                         \
+  class Name##Assembler : public BaseAssembler {                      \
+   public:                                                            \
+    explicit Name##Assembler(compiler::CodeAssemblerState* state,     \
+                             Bytecode bytecode, OperandScale scale)   \
+        : BaseAssembler(state, bytecode, scale) {}                    \
+    Name##Assembler(const Name##Assembler&) = delete;                 \
+    Name##Assembler& operator=(const Name##Assembler&) = delete;      \
+    static void Generate(compiler::CodeAssemblerState* state,         \
+                         OperandScale scale);                         \
+                                                                      \
+   private:                                                           \
+    void GenerateImpl();                                              \
+  };                                                                  \
+  void Name##Assembler::Generate(compiler::CodeAssemblerState* state, \
+                                 OperandScale scale) {                \
+    Name##Assembler assembler(state, Bytecode::k##Name, scale);       \
+    state->SetInitialDebugInformation(#Name, __FILE__, __LINE__);     \
+    assembler.GenerateImpl();                                         \
+  }                                                                   \
+  void Name##Assembler::GenerateImpl()
+//=======================================================
+//=====================分隔线==================================
+//=======================================================
+// LdaZero
+//
+// Load literal '0' into the accumulator.
+IGNITION_HANDLER(LdaZero, InterpreterAssembler) {
+  TNode<Number> zero_value = NumberConstant(0.0);
+  SetAccumulator(zero_value);
+  Dispatch();
+}
+```
+`IGNITION_HANDLER`是宏模板，`Name`是字节码名字，`BaseAssembler`是字节码的父类，`IGNITION_HANDLER(LdaZero, InterpreterAssembler)`这条语句是成生`LdaZero`的handler。`Dispatch()`是前面说的“dispatch table”，它的作用是执行下一条字节码，可以理解为寄存`eip++`，下面是`Dispatch()`的具体实现：
+```C++
+void InterpreterAssembler::Dispatch() {
+  Comment("========= Dispatch");
+  DCHECK_IMPLIES(Bytecodes::MakesCallAlongCriticalPath(bytecode_), made_call_);
+  TNode<IntPtrT> target_offset = Advance();
+  TNode<WordT> target_bytecode = LoadBytecode(target_offset);
+  DispatchToBytecodeWithOptionalStarLookahead(target_bytecode);
+}
+
+void InterpreterAssembler::DispatchToBytecodeWithOptionalStarLookahead(
+    TNode<WordT> target_bytecode) {
+  if (Bytecodes::IsStarLookahead(bytecode_, operand_scale_)) {
+    StarDispatchLookahead(target_bytecode);
+  }
+  DispatchToBytecode(target_bytecode, BytecodeOffset());
+}
+```
+`LoadBytecode(target_offset)`获取下一条字节码，`DispatchToBytecodeWithOptionalStarLookahead(target_bytecode)`负责跳转到下一条字节码并执行。  
+上面讲了字节码的生成方式，以及程序运行期进入下一条字节码的方式(dispatch)，下面的代码是生成所有的字节码处理程序。  
+```C++
+Handle<Code> GenerateBytecodeHandler(Isolate* isolate, const char* debug_name,
+                                     Bytecode bytecode,
+                                     OperandScale operand_scale,
+                                     Builtin builtin,
+                                     const AssemblerOptions& options) {
+  Zone zone(isolate->allocator(), ZONE_NAME, kCompressGraphZone);
+  compiler::CodeAssemblerState state(
+      isolate, &zone, InterpreterDispatchDescriptor{},
+      CodeKind::BYTECODE_HANDLER, debug_name,
+      builtin);
+
+  switch (bytecode) {
+#define CALL_GENERATOR(Name, ...)                     \
+  case Bytecode::k##Name:                             \
+    Name##Assembler::Generate(&state, operand_scale); \
+    break;
+    BYTECODE_LIST_WITH_UNIQUE_HANDLERS(CALL_GENERATOR);
+#undef CALL_GENERATOR
+    case Bytecode::kIllegal:
+      IllegalAssembler::Generate(&state, operand_scale);
+      break;
+    case Bytecode::kStar0:
+      Star0Assembler::Generate(&state, operand_scale);
+      break;
+    default:
+      UNREACHABLE();
+  }
+//............省略代码...................
+}
+```
+`GenerateBytecodeHandler()`函数是生成字节码处理程序的入口，由它负责调用上面的`IGNITION_HANDLER(XXX,YYY)`宏模板，完成所有字节码处理程序的生成，`GenerateBytecodeHandler()`由TurbFan启动，一句话总结：每一个字节码处理程序由Turbofan独立生成且作为`Handle<Code>`存在，最终会写进`snapshot_blob.bin`文件中。  
+好了，今天到这里，下次见。   
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap8-0929/f1.png b/chap8-0929/f1.png
new file mode 100644
index 0000000..55c28f4
Binary files /dev/null and b/chap8-0929/f1.png differ
diff --git a/chap8-0929/f2.png b/chap8-0929/f2.png
new file mode 100644
index 0000000..a2a8d19
Binary files /dev/null and b/chap8-0929/f2.png differ
diff --git a/chap9-1002/README.md b/chap9-1002/README.md
new file mode 100644
index 0000000..5a97142
--- /dev/null
+++ b/chap9-1002/README.md
@@ -0,0 +1,355 @@
+# 连载《Chrome V8 原理讲解》第九篇 Builtin源码分析
+
+![avatar](../v8.png)
+# 1 摘要 
+上一篇文章中，Builtin作为先导知识，我们做了宏观概括和介绍。Builtin（Built-in function）是编译好的内置代码块（chunk），存储在`snapshot_blob.bin`文件中，V8启动时以反序列化方式加载，运行时可以直接调用。Builtins功能共计600多个，细分为多个子类型，涵盖了解释器、字节码、执行单元等多个V8核心功能，本文从微观角度剖析Builtins功能的源码，在不使用`snapshot_blob.bin`文件的情况下，详细说明Builtin创建和运行过程。
+本文内容组织结构：Bultin初始化过程（章节2），Builtin子类型讲解(章节3)。  
+# 2 Builtin初始化  
+下面是`code`类，它负责管理所有`Builtin`功能，是`builtin table`的数据类型。
+```c++
+1.  class Code : public HeapObject {
+2.   public:
+3.    NEVER_READ_ONLY_SPACE
+4.    // Opaque data type for encapsulating code flags like kind, inline
+5.    // cache state, and arguments count.
+6.    using Flags = uint32_t;
+7.  #define CODE_KIND_LIST(V)   \
+8.    V(OPTIMIZED_FUNCTION)     \
+9.    V(BYTECODE_HANDLER)       \
+10.   V(STUB)                   \
+11.    V(BUILTIN)                \
+12.    V(REGEXP)                 \
+13.    V(WASM_FUNCTION)          \
+14.    V(WASM_TO_CAPI_FUNCTION)  \
+15.    V(WASM_TO_JS_FUNCTION)    \
+16.    V(JS_TO_WASM_FUNCTION)    \
+17.    V(JS_TO_JS_FUNCTION)      \
+18.    V(WASM_INTERPRETER_ENTRY) \
+19.    V(C_WASM_ENTRY)
+20.    enum Kind {
+21.  #define DEFINE_CODE_KIND_ENUM(name) name,
+22.      CODE_KIND_LIST(DEFINE_CODE_KIND_ENUM)
+23.  #undef DEFINE_CODE_KIND_ENUM
+24.          NUMBER_OF_KINDS
+25.    };
+26.    static const char* Kind2String(Kind kind);
+27.    // Layout description.
+28.  #define CODE_FIELDS(V)                                                    \
+29.    V(kRelocationInfoOffset, kTaggedSize)                                   \
+30.    V(kDeoptimizationDataOffset, kTaggedSize)                               \
+31.    V(kSourcePositionTableOffset, kTaggedSize)                              \
+32.    V(kCodeDataContainerOffset, kTaggedSize)                                \
+33.    /* Data or code not directly visited by GC directly starts here. */     \
+34.    /* The serializer needs to copy bytes starting from here verbatim. */   \
+35.    /* Objects embedded into code is visited via reloc info. */             \
+36.    V(kDataStart, 0)                                                        \
+37.    V(kInstructionSizeOffset, kIntSize)                                     \
+38.    V(kFlagsOffset, kIntSize)                                               \
+39.    V(kSafepointTableOffsetOffset, kIntSize)                                \
+40.    V(kHandlerTableOffsetOffset, kIntSize)                                  \
+41.    V(kConstantPoolOffsetOffset,                                            \
+42.      FLAG_enable_embedded_constant_pool ? kIntSize : 0)                    \
+43.    V(kCodeCommentsOffsetOffset, kIntSize)                                  \
+44.    V(kBuiltinIndexOffset, kIntSize)                                        \
+45.    V(kUnalignedHeaderSize, 0)                                              \
+46.    /* Add padding to align the instruction start following right after */  \
+47.    /* the Code object header. */                                           \
+48.    V(kOptionalPaddingOffset, CODE_POINTER_PADDING(kOptionalPaddingOffset)) \
+49.    V(kHeaderSize, 0)
+50.    DEFINE_FIELD_OFFSET_CONSTANTS(HeapObject::kHeaderSize, CODE_FIELDS)
+51.  #undef CODE_FIELDS
+52.    STATIC_ASSERT(FIELD_SIZE(kOptionalPaddingOffset) == kHeaderPaddingSize);
+53.    inline int GetUnwindingInfoSizeOffset() const;
+54.    class BodyDescriptor;
+55.    // Flags layout.  BitField<type, shift, size>.
+56.  #define CODE_FLAGS_BIT_FIELDS(V, _)    \
+57.    V(HasUnwindingInfoField, bool, 1, _) \
+58.    V(KindField, Kind, 5, _)             \
+59.    V(IsTurbofannedField, bool, 1, _)    \
+60.    V(StackSlotsField, int, 24, _)       \
+61.    V(IsOffHeapTrampoline, bool, 1, _)
+62.    DEFINE_BIT_FIELDS(CODE_FLAGS_BIT_FIELDS)
+63.  #undef CODE_FLAGS_BIT_FIELDS
+64.    static_assert(NUMBER_OF_KINDS <= KindField::kMax, "Code::KindField size");
+65.    static_assert(IsOffHeapTrampoline::kLastUsedBit < 32,
+66.                  "Code::flags field exhausted");
+67.    // KindSpecificFlags layout (STUB, BUILTIN and OPTIMIZED_FUNCTION)
+68.  #define CODE_KIND_SPECIFIC_FLAGS_BIT_FIELDS(V, _) \
+69.    V(MarkedForDeoptimizationField, bool, 1, _)     \
+70.    V(EmbeddedObjectsClearedField, bool, 1, _)      \
+71.    V(DeoptAlreadyCountedField, bool, 1, _)         \
+72.    V(CanHaveWeakObjectsField, bool, 1, _)          \
+73.    V(IsPromiseRejectionField, bool, 1, _)          \
+74.    V(IsExceptionCaughtField, bool, 1, _)
+75.    DEFINE_BIT_FIELDS(CODE_KIND_SPECIFIC_FLAGS_BIT_FIELDS)
+76.  #undef CODE_KIND_SPECIFIC_FLAGS_BIT_FIELDS
+77.   private:
+78.    friend class RelocIterator;
+79.    bool is_promise_rejection() const;
+80.    bool is_exception_caught() const;
+81.    OBJECT_CONSTRUCTORS(Code, HeapObject);  
+82.  };
+//........................代码太长，省略很多.....................
+//.............................................................
+```  
+上述代码中，`CODE_KIND_LIST`从code角度定义了类型，在`Builtin`类中也定义了`Builtin`一共有七种子类型，这是两种不同的定义方式，但说的都是Builtin。`Builtin`的初始化工作由方法`void Isolate::Initialize(Isolate* isolate,const v8::Isolate::CreateParams& params)`统一完成，下面给出这个方法的部分代码。
+```c++
+1.  void Isolate::Initialize(Isolate* isolate,
+2.                           const v8::Isolate::CreateParams& params) {
+3.    i::Isolate* i_isolate = reinterpret_cast<i::Isolate*>(isolate);
+4.    CHECK_NOT_NULL(params.array_buffer_allocator);
+5.    i_isolate->set_array_buffer_allocator(params.array_buffer_allocator);
+6.    if (params.snapshot_blob != nullptr) {
+7.      i_isolate->set_snapshot_blob(params.snapshot_blob);
+8.    } else {
+9.      i_isolate->set_snapshot_blob(i::Snapshot::DefaultSnapshotBlob());
+10.   }
+11.    auto code_event_handler = params.code_event_handler;
+12.  //........................代码太长，省略很多.....................
+13.    if (!i::Snapshot::Initialize(i_isolate)) {
+14.      // If snapshot data was provided and we failed to deserialize it must
+15.      // have been corrupted.
+16.      if (i_isolate->snapshot_blob() != nullptr) {
+17.        FATAL(
+18.            "Failed to deserialize the V8 snapshot blob. This can mean that the "
+19.            "snapshot blob file is corrupted or missing.");
+20.      }
+21.      base::ElapsedTimer timer;
+22.      if (i::FLAG_profile_deserialization) timer.Start();
+23.      i_isolate->InitWithoutSnapshot();
+24.      if (i::FLAG_profile_deserialization) {
+25.        double ms = timer.Elapsed().InMillisecondsF();
+26.        i::PrintF("[Initializing isolate from scratch took %0.3f ms]\n", ms);
+27.      }
+28.    }
+29.    i_isolate->set_only_terminate_in_safe_scope(
+30.        params.only_terminate_in_safe_scope);
+31.  }
+```
+上述方面中进入第22行，最终进入下面的Builtin初始化方法。
+```c++
+1.  void SetupIsolateDelegate::SetupBuiltinsInternal(Isolate* isolate) {
+2.  //...................删除部分代码，留下最核心功能
+3.  //...................删除部分代码，留下最核心功能
+4.    int index = 0;
+5.    Code code;
+6.  #define BUILD_CPP(Name)                                                      \
+7.    code = BuildAdaptor(isolate, index, FUNCTION_ADDR(Builtin_##Name), #Name); \
+8.    AddBuiltin(builtins, index++, code);
+9.  #define BUILD_TFJ(Name, Argc, ...)                              \
+10.   code = BuildWithCodeStubAssemblerJS(                          \
+11.        isolate, index, &Builtins::Generate_##Name, Argc, #Name); \
+12.    AddBuiltin(builtins, index++, code);
+13.  #define BUILD_TFC(Name, InterfaceDescriptor)                      \
+14.    /* Return size is from the provided CallInterfaceDescriptor. */ \
+15.    code = BuildWithCodeStubAssemblerCS(                            \
+16.        isolate, index, &Builtins::Generate_##Name,                 \
+17.        CallDescriptors::InterfaceDescriptor, #Name);               \
+18.    AddBuiltin(builtins, index++, code);
+19.  #define BUILD_TFS(Name, ...)                                                   \
+20.    /* Return size for generic TF builtins (stub linkage) is always 1. */        \
+21.    code =                                                                       \
+22.        BuildWithCodeStubAssemblerCS(isolate, index, &Builtins::Generate_##Name, \
+23.                                     CallDescriptors::Name, #Name);              \
+24.    AddBuiltin(builtins, index++, code);
+25.  #define BUILD_TFH(Name, InterfaceDescriptor)              \
+26.    /* Return size for IC builtins/handlers is always 1. */ \
+27.    code = BuildWithCodeStubAssemblerCS(                    \
+28.        isolate, index, &Builtins::Generate_##Name,         \
+29.        CallDescriptors::InterfaceDescriptor, #Name);       \
+30.    AddBuiltin(builtins, index++, code);
+31.  #define BUILD_BCH(Name, OperandScale, Bytecode)                           \
+32.    code = GenerateBytecodeHandler(isolate, index, OperandScale, Bytecode); \
+33.    AddBuiltin(builtins, index++, code);
+34.  #define BUILD_ASM(Name, InterfaceDescriptor)                                \
+35.    code = BuildWithMacroAssembler(isolate, index, Builtins::Generate_##Name, \
+36.                                   #Name);                                    \
+37.    AddBuiltin(builtins, index++, code);
+38.    BUILTIN_LIST(BUILD_CPP, BUILD_TFJ, BUILD_TFC, BUILD_TFS, BUILD_TFH, BUILD_BCH,
+39.                 BUILD_ASM);
+40.  //...................删除部分代码，留下最核心功能
+41.  //...................删除部分代码，留下最核心功能
+42.  }
+```
+上述代码只保留了最核心的Builtin初始化功能，初始化工作的主要是生成并编译Builtin代码，并以独立功能的形式挂载到`isolate`上，以`BuildWithCodeStubAssemblerCS()`详细描述该过程。  
+见下面代码，第一个参数是`isolate`，用于保存初化完成的`Builtin`；第二个参数全局变量`index`，`Builtin`存储在`isolate`的数组成员中，`index`是数组下标；第三个参数`generator`是函数指针，该函数用于生成`Builtin`；第四个参数是call描述符；最后一个是函数名字。  
+```c++
+1.  // Builder for builtins implemented in TurboFan with CallStub linkage.
+2.  Code BuildWithCodeStubAssemblerCS(Isolate* isolate, int32_t builtin_index,
+3.                                    CodeAssemblerGenerator generator,
+4.                                    CallDescriptors::Key interface_descriptor,
+5.                                    const char* name) {
+6.    HandleScope scope(isolate);
+7.    // Canonicalize handles, so that we can share constant pool entries pointing
+8.    // to code targets without dereferencing their handles.
+9.    CanonicalHandleScope canonical(isolate);
+10.   Zone zone(isolate->allocator(), ZONE_NAME);
+11.    // The interface descriptor with given key must be initialized at this point
+12.    // and this construction just queries the details from the descriptors table.
+13.    CallInterfaceDescriptor descriptor(interface_descriptor);
+14.    // Ensure descriptor is already initialized.
+15.    DCHECK_LE(0, descriptor.GetRegisterParameterCount());
+16.    compiler::CodeAssemblerState state(
+17.        isolate, &zone, descriptor, Code::BUILTIN, name,
+18.        PoisoningMitigationLevel::kDontPoison, builtin_index);
+19.    generator(&state);
+20.    Handle<Code> code = compiler::CodeAssembler::GenerateCode(
+21.        &state, BuiltinAssemblerOptions(isolate, builtin_index));
+22.    return *code;
+23.  }
+```
+在代码中，第19行代码生成Builtin源码，以第一个Builtin为例说明`generator(&state)`的功能，此时`generator`指针代表的函数是`TF_BUILTIN(RecordWrite, RecordWriteCodeStubAssembler) `，下面是代码：
+```c++
+1.  TF_BUILTIN(RecordWrite, RecordWriteCodeStubAssembler) {
+2.    Label generational_wb(this);
+3.    Label incremental_wb(this);
+4.    Label exit(this);
+5.    Node* remembered_set = Parameter(Descriptor::kRememberedSet);
+6.    Branch(ShouldEmitRememberSet(remembered_set), &generational_wb,
+7.           &incremental_wb);
+8.    BIND(&generational_wb);
+9.    {
+10.     Label test_old_to_young_flags(this);
+11.      Label store_buffer_exit(this), store_buffer_incremental_wb(this);
+12.      TNode<IntPtrT> slot = UncheckedCast<IntPtrT>(Parameter(Descriptor::kSlot));
+13.      Branch(IsMarking(), &test_old_to_young_flags, &store_buffer_exit);
+14.      BIND(&test_old_to_young_flags);
+15.      {
+16.        TNode<IntPtrT> value =
+17.            BitcastTaggedToWord(Load(MachineType::TaggedPointer(), slot));
+18.        TNode<BoolT> value_is_young =
+19.            IsPageFlagSet(value, MemoryChunk::kIsInYoungGenerationMask);
+20.        GotoIfNot(value_is_young, &incremental_wb);
+21.        TNode<IntPtrT> object =
+22.            BitcastTaggedToWord(Parameter(Descriptor::kObject));
+23.        TNode<BoolT> object_is_young =
+24.            IsPageFlagSet(object, MemoryChunk::kIsInYoungGenerationMask);
+25.        Branch(object_is_young, &incremental_wb, &store_buffer_incremental_wb);
+26.      }
+27.      BIND(&store_buffer_exit);
+28.      {
+29.        TNode<ExternalReference> isolate_constant =
+30.            ExternalConstant(ExternalReference::isolate_address(isolate()));
+31.        Node* fp_mode = Parameter(Descriptor::kFPMode);
+32.        InsertToStoreBufferAndGoto(isolate_constant, slot, fp_mode, &exit);
+33.      }
+34.      BIND(&store_buffer_incremental_wb);
+35.      {
+36.        TNode<ExternalReference> isolate_constant =
+37.            ExternalConstant(ExternalReference::isolate_address(isolate()));
+38.        Node* fp_mode = Parameter(Descriptor::kFPMode);
+39.        InsertToStoreBufferAndGoto(isolate_constant, slot, fp_mode,
+40.                                   &incremental_wb);
+41.      }
+42.    } //........................省略代码......................................
+43.    BIND(&exit);
+44.    IncrementCounter(isolate()->counters()->write_barriers(), 1);
+45.    Return(TrueConstant());
+46.  }
+```
+这个函数`TF_BUILTIN(RecordWrite, RecordWriteCodeStubAssembler)`是生成器，它的作用是生成写记录功能的源代码，`TF_BUILTIN`是宏模板，展开后可以看到它的类成员`CodeAssemblerState* state`保存了生成之后的源码。“用平台无关的生成器为特定平台生成源代码”是`Builtin`的常用做法，这样减少了工作量。函数执行完成后返回到`BuildWithCodeStubAssemblerCS`，生成的源代码经过处理后，最终由`code`表示，下面是`code`的数据类型。  
+
+```c++
+class Code : public HeapObject {
+ public:
+  NEVER_READ_ONLY_SPACE
+  // Opaque data type for encapsulating code flags like kind, inline
+  // cache state, and arguments count.
+  using Flags = uint32_t;
+
+#define CODE_KIND_LIST(V)   \
+  V(OPTIMIZED_FUNCTION)     \
+  V(BYTECODE_HANDLER)       \
+  V(STUB)                   \
+  V(BUILTIN)                \
+  V(REGEXP)                 \
+  V(WASM_FUNCTION)          \
+  V(WASM_TO_CAPI_FUNCTION)  \
+  V(WASM_TO_JS_FUNCTION)    \
+  V(JS_TO_WASM_FUNCTION)    \
+  V(JS_TO_JS_FUNCTION)      \
+  V(WASM_INTERPRETER_ENTRY) \
+  V(C_WASM_ENTRY)
+
+  enum Kind {
+#define DEFINE_CODE_KIND_ENUM(name) name,
+    CODE_KIND_LIST(DEFINE_CODE_KIND_ENUM)
+#undef DEFINE_CODE_KIND_ENUM
+        NUMBER_OF_KINDS
+  };
+//..................省略........................
+//.............................................
+```  
+上述代码中，可以看到从`code`的角度对`Builtin`进行了更详细的分类。另外`code`是堆对象，也就是说`Builtin`是由V8的堆栈进行管理，后续讲到堆栈时再详细说明这部分知识。图2给出函数调用堆栈，供读者自行复现。  
+
+![avatar](f1.png)  
+在`SetupBuiltinsInternal()`中可以看到`AddBuiltin()`将生成的`code`代码添加到`isolate`中，代码如下。  
+
+```c++
+void SetupIsolateDelegate::AddBuiltin(Builtins* builtins, int index,
+                                      Code code) {
+  DCHECK_EQ(index, code.builtin_index());
+  builtins->set_builtin(index, code);
+}
+//..............分隔线......................
+void Builtins::set_builtin(int index, Code builtin) {
+  isolate_->heap()->set_builtin(index, builtin);
+}
+```
+所有`Builtin`功能生成后保存在`Address builtins_[Builtins::builtin_count]`中，初始化方法`SetupBuiltinsInternal`按照`BUILTIN_LIST`的定义顺序依次完成所有Builtin的源码生成、编译和挂载到isolate。  
+# 2 Builtin子类型
+从`Builtins`的功能看，它包括了：Ignition实现、字节码实现、以及ECMA规范实现等众多V8的核心功能，在`BUILTIN_LIST`定义中有详细注释，请读者自行查阅。前面讲过，从`BUILTIN`的实现角度分为七种类型，见下面代码：  
+```c++
+#define BUILD_CPP(Name)
+#define BUILD_TFJ(Name, Argc, ...) 
+#define BUILD_TFC(Name, InterfaceDescriptor)  
+#define BUILD_TFS(Name, ...) 
+#define BUILD_TFH(Name, InterfaceDescriptor) 
+#define BUILD_BCH(Name, OperandScale, Bytecode)  
+#define BUILD_ASM(Name, InterfaceDescriptor)
+```
+
+以子类型`BUILD_CPP`举例说明，下面是完整源代码。  
+
+```c++
+1.  Code BuildAdaptor(Isolate* isolate, int32_t builtin_index,
+2.                    Address builtin_address, const char* name) {
+3.    HandleScope scope(isolate);
+4.    // Canonicalize handles, so that we can share constant pool entries pointing
+5.    // to code targets without dereferencing their handles.
+6.    CanonicalHandleScope canonical(isolate);
+7.    constexpr int kBufferSize = 32 * KB;
+8.    byte buffer[kBufferSize];
+9.    MacroAssembler masm(isolate, BuiltinAssemblerOptions(isolate, builtin_index),
+10.                       CodeObjectRequired::kYes,
+11.                        ExternalAssemblerBuffer(buffer, kBufferSize));
+12.    masm.set_builtin_index(builtin_index);
+13.    DCHECK(!masm.has_frame());
+14.    Builtins::Generate_Adaptor(&masm, builtin_address);
+15.    CodeDesc desc;
+16.    masm.GetCode(isolate, &desc);
+17.    Handle<Code> code = Factory::CodeBuilder(isolate, desc, Code::BUILTIN)
+18.                            .set_self_reference(masm.CodeObject())
+19.                            .set_builtin_index(builtin_index)
+20.                            .Build();
+21.    return *code;
+22.  }
+```
+`BuildAdaptor`的生成功能由第13行代码实现，最终该代码的实现如下：  
+```c++
+void Builtins::Generate_Adaptor(MacroAssembler* masm, Address address) {
+  __ LoadAddress(kJavaScriptCallExtraArg1Register,
+                 ExternalReference::Create(address));
+  __ Jump(BUILTIN_CODE(masm->isolate(), AdaptorWithBuiltinExitFrame),
+          RelocInfo::CODE_TARGET);
+}
+}
+```  
+上面两部分代码实现了第77号`Builtin`功能，名字是`HandleApiCall`，图2以`char`类型展示了生成的源代码。  
+
+![avatar](f2.png)  
+
+总结：学习Builtin时，涉及很多系统结构相关的知识，本文讲解采用的是x64架构。每种`Builtin`的生成方式虽不相同，但分析源码的思路相同，有问题可以联系我。  
+好了，今天到这里，下次见。   
+**恳请读者批评指正、提出宝贵意见**  
+**微信：qq9123013  备注：v8交流    邮箱：v8blink@outlook.com**
\ No newline at end of file
diff --git a/chap9-1002/f1.png b/chap9-1002/f1.png
new file mode 100644
index 0000000..742b801
Binary files /dev/null and b/chap9-1002/f1.png differ
diff --git a/chap9-1002/f2.png b/chap9-1002/f2.png
new file mode 100644
index 0000000..19137a8
Binary files /dev/null and b/chap9-1002/f2.png differ
diff --git a/readme.md b/readme.md
new file mode 100644
index 0000000..22bc571
--- /dev/null
+++ b/readme.md
@@ -0,0 +1,29 @@
+# 《Chrome V8原理讲解》系列技术文章，3~4天一篇，持续更新中...   
+![avatar](v8.png) 
+V8是chrome核心组件，重要程度不用多言。本系列文章，讲解V8源码，力求做到全面覆盖知识点、有理论支撑，做到细致讲解源码、有实践依据。  
+
+**安全客**：https://www.anquanke.com/member.html?memberId=161290    
+**知乎** ： https://www.zhihu.com/people/v8blink  
+**知乎和GitHub延后一周更新** 
+
+我是**灰豆**，吃饭睡觉打豆豆。  
+
+# 目录
+《Chrome V8原理讲解》第十八篇 利用汇编看V8，洞察看不见的行为  
+《Chrome V8原理讲解》第十七篇 JS对象的内存布局与创建过程  
+《Chrome V8原理讲解》第十六篇 运行时辅助类，详解加载与调用过程  
+《Chrome V8原理讲解》第十五篇 运行时辅助类，给V8加钩子函数  
+《Chrome V8原理讲解》第十四篇 看V8如何表示JS的动态类型  
+《Chrome V8原理讲解》第十三篇 String类方法的源码分析  
+《Chrome V8原理讲解》第十二篇 JSFunction源码分析   
+《Chrome V8 原理讲解》第十一篇 字节码调度 Dispatch机制  
+《Chrome V8 原理讲解》第十篇 V8 Execution源码分析  
+《Chrome V8 原理讲解》第九篇 Builtin源码分析  
+《Chrome V8 原理讲解》第八篇 解释器Ignition  
+《Chrome V8 原理讲解》第七篇 V8堆栈框架 Stack Frame  
+《Chrome V8 原理讲解》第六篇 bytecode字节码生成  
+《Chrome V8 原理讲解》第五篇 V8语法分析器源码讲解  
+《Chrome V8 原理讲解》第四篇 V8词法分析源码讲解，Token字生成  
+《Chrome V8 原理讲解》第三篇 看V8编译流程，学习词法分析  
+《Chrome V8 原理讲解》第二篇 鸟瞰V8运行过程，形成大局观  
+《Chrome V8 原理讲解》第一篇：V8环境搭建    
diff --git a/v8.png b/v8.png
new file mode 100644
index 0000000..3e723a6
Binary files /dev/null and b/v8.png differ